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 112350

Article: 112350
Subject: timing constraints
From: "ram" <vsrpkumar@rediffmail.com>
Date: 20 Nov 2006 20:34:35 -0800
Links: << >>  << T >>  << A >>
In the cyclone devices,
How to set parameters like tco,tsu,th,tpd.I am not using any M4K RAMS
or DSP blocks.I am using for LE_FF timing and LVTTl standards.I am not
using fast corner analysis.I have to fix up hold violations of no 96 I
referred cyclone II device data sheet DC and timing characteristics
page 106-135.How to set this paramters.There are no examples for
this.Can you provide examples for this.If you provide examples for this
in assignment editor ,it will be useful for users
kumar


Article: 112351
Subject: timing constraints
From: "ram" <vsrpkumar@rediffmail.com>
Date: 20 Nov 2006 20:34:52 -0800
Links: << >>  << T >>  << A >>
In the cyclone devices,
How to set parameters like tco,tsu,th,tpd.I am not using any M4K RAMS
or DSP blocks.I am using for LE_FF timing and LVTTL standards.I am not
using fast corner analysis.I have to fix up hold violations of no 96 I
referred cyclone II device data sheet DC and timing characteristics
page 106-135.How to set this paramters.There are no examples for
this.Can you provide examples for this.If you provide examples for this
in assignment editor ,it will be useful for users
kumar


Article: 112352
Subject: Re: Semantics or examples for Xilinx xgpio driver under Linux?
From: sdave@ufl.edu
Date: 20 Nov 2006 20:42:46 -0800
Links: << >>  << T >>  << A >>
Mind posting a sample you used to access the LEDs or switches?

On Oct 26, 5:17 pm, Neil Steiner <neil.steiner@vt.edu> wrote:
> Ah, I see.  The functionality is supported through ioctl() and struct
> ibm_gpio_ioctl_data.  A little strange, but okay.


Article: 112353
Subject: Re: What's wrong with my tcl example in Quartus?
From: "Alan Nishioka" <alan@nishioka.com>
Date: 20 Nov 2006 22:47:43 -0800
Links: << >>  << T >>  << A >>
fl wrote:
> Info: Selected device EP1C12Q240C6 for design "filtref"
> Info: Fitter is performing a Standard Fit compilation using maximum
> Fitter effort to optimize design performance
> Error: Can't place node "clk" -- illegal location assignment PIN_G1
> Error: Can't fit design in device
> Error: Quartus II Fitter was unsuccessful. 2 errors, 0 warnings

Well I haven't used Altera for a while, but it looks like an
EP1C12Q240C6 is a 240 pin PQFP and doesn't have a pin G1.

Either you need to change the part or you need to change the pin.

Alan Nishioka


Article: 112354
Subject: Re: pulse jitter due to clock
From: Al <alessandro.basili@cern.ch>
Date: Tue, 21 Nov 2006 09:10:42 +0100
Links: << >>  << T >>  << A >>
Kolja Sulimma wrote:
>>
>>
>>Let me guess an Acam part?

We did have some experience with Acam.
> 
> Could also be from MSC in Darmstadt, but as he has a CERN email address
> I am sure he is using the HPTDC developed at CERN. The HPTDC homepage
> has vanished, but we use it in one of our TDC boards:
> http://cronologic.de/products/time_measurement/hptdc/

Exactly!
> 
> 
>>>Can anyone say something about this? Does it sound reasonable?
> 
> 
> Slow input slopes create crosstalk in the HPTDC. Therefore it makes
> sense to have extremely fast LVDS input buffers in front of the chip
> anyway. If you use buffers with enable (or an AND-gate) you can control
> that from the FPGA to mask the signals. No need to route the signals
> through the FPGA.

The big problem is that, as in all time measurements in physics, there 
will be a "trigger" configuration which will allow the time conversion. 
This will need to be implemented in an FPGA, because different "trigger" 
configurations will be needed.
Because of that all the signals will come from an FPGA or from a 
combinational logic anyway.
After that we can use all the drivers we want to minimize later sigma 
increase on the measurement, but still the source will jitter.
My initial question was about the jitter increase due to the presence of 
a clock signal running through the FPGA, not that this clock source will 
have anything logically related to the output signals to be measured.
We are getting signals from PMTs (PhotoMultiplierTubes), so they are 
single ended signals and there is no such a gain to convert them in LVDS 
signal and then convert them again to TTL inside the HPTDC. All these 
intermediate stages will drammatically add their sigma worsening the 
overall measurement.

I saw your PCI board with the  HPTDC installed, wich type of LVDS 
drivers did you inserted in between NIM and HPTDC?

We are using a configuration such that to use the TTL port of the HPTDC 
and a fast comparator with a configurable threshold and an 
amplitude-time correction algorithm to correct the time-walk errors on 
different amplitude signals.

Regards

Al


-- 
Alessandro Basili
CERN, PH/UGC
Hardware Designer

Article: 112355
Subject: Re: DDR_VDHL_models
From: helmut.leonhardt@gmail.com
Date: 21 Nov 2006 00:19:07 -0800
Links: << >>  << T >>  << A >>
http://www.freemodelfoundry.com/
www.hynix.com
http://www.qimonda.com/

Bye Helmut

Vangelis wrote:
> Does anynone know where can I find VHDL models for DDR modules? I have an XUP board and I want to run some simulations before downloading my design to the FPGA. I am not looking for a specific model. Any generic DDR model will do the job.


Article: 112356
Subject: Re: pulse jitter due to clock
From: Al <alessandro.basili@cern.ch>
Date: Tue, 21 Nov 2006 09:39:14 +0100
Links: << >>  << T >>  << A >>
Austin Lesea wrote:
> Al,
> 
> Passing a signal through an FPGA, and then expecting to resolve 25 ps is
> not a good idea.
> 
> The FPGA may add as much as thousands (yes thousands) of picoseconds of
> jitter:  it all depends on the number of clocks running, their
> frequencies, if they are asynchronous or not, the number of CLB flip
> flops toggling (internal simultaneous switching), and the number of
> external IOs switching (SSO noise).
> 
> Additionally, since jitter is caused by anything being less than
> perfect, this also includes the power distribution network, and the
> signal integrity of all the traces (rise times, fall times, reflections,
> etc.).
> 
> The jitter floor for a FPGA that is doing nothing at all (signal in,,
> signal out) is probably around 35 picoseconds peak to peak.  A
> completely synchronous design with everything done perfectly will
> probably come in at around 150 picoseconds, peak to peak jitter.

I'm sorry Austin I didn't get your point at all. I'm not talking about 
delay (and I think you got this), so how can a signal-in signal-out add 
35 picoseconds jitter? You said peak to peak but maybe I didn't explain 
what jitter is to me:

Given a fixed source that we know is stable in time (no matter how) and 
a signal produced from this source with some combinational logic and 
delay (like cables and I/O delay), the output distribution will be 
gaussian if we have a white-noise environment. The jitter I'm talking 
about will be (basically) the sigma of this distribution.
> 
> An ASIC is probably the last thing I would choose to do jitter
> measurement.  As I have said, you do anything wrong (at all), and you
> will fail.

Is that mean that all these ASIC TDC you find around are just junk? They 
are ASIC, nothing more, just dedicated device to measure Time. There are 
basically two types of TDC AFAIK:

1) time expantion based: which is an amplitude measurement that is 
proportional to a time measurement
2) Calibrated standard-cell delay to shift in the value.

In the latest the measurement is quite more precise because typically 
the time-expansion circuitry is an analogue circuit which has a much 
worse stability then an integrated standard-cell delay.

Sorry I didn't understand this as well, what do you mean by

> Jitter is the result of converting amplitude variations into
> phase variations

..

> 
> To resolve the time you desire, it requires very high speed design
> (PECL), and virtually perfect power distribution, and signal integrity.

I do agree power distribution has a major effect on the time 
measurement, but that's why "calibration procedures" have been invented. 
You basically subtract (is a deconvolution operation to be precise, even 
though many physicists deny it) the environment noise from the 
meauserements. This operation is quite complicated because you need to 
insure that power consumption doesn't vary so that will affect the 
measurement.
> 
> I hope others here on the newsgroup will provide you with some better
> guidance, as all I have done is explained the problems.

Explaining problems is a great guidance, but I think I misused the word 
jitter and maybe I failed explaining my problem.

> 
> Austin
> 
> 
> 
> Al wrote:
> 
>>Hi to everyone,
>>I'm developing some electronics to make a time measurement with a
>>resolution of 25 ps. I'm using a dedicated ASIC to do so but I'm giving
>>the signals to the ASIC through an FPGA.
>>The way is very simple, basically I have some signals coming to my fpga
>>which I will mask with some combinatorial logic and a configurable
>>register so that I can allow some measurements or some others. The
>>output of this "masking" will go to the ASIC.
>>They assert (and here is the question) that a clocked device as an FPGA
>>may add some jitter to the signals due to the substrate  current
>>overload (for the presence of the clock) that will lead to some 15 ps
>>jitter over the signals. I don't know how they could resolve this value
>>but I'm assuming they were telling the truth about numbers (at least,
>>while I have some doubts about explanation of those numbers).
>>Can anyone say something about this? Does it sound reasonable?
>>
>>Al
>>


-- 
Alessandro Basili
CERN, PH/UGC
Hardware Designer

Article: 112357
Subject: Re: pulse jitter due to clock
From: Al <alessandro.basili@cern.ch>
Date: Tue, 21 Nov 2006 09:51:31 +0100
Links: << >>  << T >>  << A >>
nospam wrote:
> 
> Let me guess an Acam part?
> 
I have some experience with Acam product, but eventually we are using 
HPTDC developped at CERN.
> 
> If you are trying to measure signals with 25ps resolution you have to be
> extremely careful with *everything* those signals pass through. 
> 
> Passing them through as little as possible would be a good starting
> approach. 

I know, but unfortunately you need to pass through some logic to be able 
to mask some signals and to be able to recognize the correct logic 
combination you want to measure (i.e. the trigger configuration). To do 
that either you use discrete components (a lot of them if you are 
talking about hundreds of signals) or you use an FPGA to select the 
correct combination.
After all that, depending on how your system is done, you need to 
distribute these signals to different boards, placed in different 
places, so you will need a TTL-LVDS and an LVDS-TTL conversion (maybe 
you can get rid of the second conversion if you are using LVDS input on 
your TDC). These pass-through are necessary to the logic of the measurement.

Of course all this logic is a combinational logic and has nothing to do 
with clock, but is it true that this logic cell delay will be changed by 
the presence of the clock inside the chip? even if this clock will not 
be connected to the combinational cell?

Thanks for your warning

Al


-- 
Alessandro Basili
CERN, PH/UGC
Hardware Designer

Article: 112358
Subject: Re: memory init in Altera bitfiles, (like data2mem) is it possible?
From: already5chosen@yahoo.com
Date: 21 Nov 2006 00:56:19 -0800
Links: << >>  << T >>  << A >>

radarman wrote:

> This is all well and good, but even with smart compilation turned on,
> things don't work quite as well as they should. I'm designing my own
> CPU core, so I'm not using NIOS, but I still need to be able to update
> BRAM's with new program code.
>
> I've already worked around (sort of) the fact that for some reason,
> Quartus won't properly update a BRAM from a .hex file. (.hex files work
> fine for compilation, but not a mif/hex update. So, I bring my .hex
> file into Quartus, and save it as a .mif file.  This is annoying, since
> I can no longer automate the whole build process. At some point, when I
> get irritated enough, I'll write a program that converts hex to mif
> correctly, but I haven't had the time for much extra programming
> lately.
>
> However, the MORE irritating problem I've run into is that if I repeat
> the mif/hex update process a second time, changing only the .mif file,
> Quartus launches into a full recompile anyway. This is a bit
> frustrating, since the "hardware" is stable at this point. I just need
> to test software. Perhaps I've missed something, but I've yet to find a
> way to avoid the full recompile on the second update.
>
> Maybe this works correctly in the NIOS flow, but I don't have that tool
> available. I did try the NIOS eval, though, and I didn't see any new
> tools in it that looked like they would solve my problem.


What version of Quartus? Service pack? Critical update?
Sounds like you were hit by that:
http://www.altera.com/support/kdb/solutions/rd03062006_72.html

BTW, if you want to minimize troubles please store you .hex files in
Quartus project directory.


Article: 112359
Subject: Re: 8080 FSGA model in an FPGA
From: "Grant Stockly" <grant@stockly.com>
Date: 21 Nov 2006 01:22:23 -0800
Links: << >>  << T >>  << A >>
Ray Andraka wrote:
> Jon Elson wrote:
>
>
> Some people have way too much time on their hands!

I want to use the transistor board set as part of a possible computer
kit / electronics trainer.  I have just completed the Altair Kit
reproduction that I've been working on for 9 months as a hobby.  If I
can stick with it and get that done on my time off, I think a
transistor 8080 would be easy.  ;)

http://www.altairkit.com
http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=250052265051

Any way, I guess I would be happy if the transistor computer were
instruction set compatible AND timing compatible.  I really am not
concerned about how the computer is constructed at the transistor
level, but I want the status signals the same and the instruction set
cycle count to be the same.  If a program depends on a software delay
loop, I would want it to be equal.

Maybe I'm trying to attempt too much.  I think my best bet is to
reasearch the 9080 emulator by AMD and duplicate that.  Its possible I
could rewrite the microcode to include status bit states.  Who knows...

With this new information, does anyone see a different easier path?  Or
am I still just plain crazy?  :)  I won't be making any transistor
8080s until I'm out from under all the investments in the Altair
project!

Grant


Article: 112360
Subject: Re: pulse jitter due to clock
From: Al <alessandro.basili@cern.ch>
Date: Tue, 21 Nov 2006 10:30:05 +0100
Links: << >>  << T >>  << A >>
PeteS wrote:
> 
> For time measurements of this order, you'll need a *very* stable and low 
> jitter clock source. I would suggest a PECL differential, or even 
> perhaps a truly stabilised (thermally) oscillator.

For any type of measurement of this order I will defenetely not use any 
clock source for different reasons:

1) power consumption, it is not reasonable to have a 20 GHz clock to 
measure 25 ps bin resolution, there are several other solutions which 
are quite less expensive in terms of power dissipation

2) low jitter clock source are very expensive and very difficult to 
verify. How would you trust your low jitter clock? from datasheet? and 
what if your clock has a bigger jitter because has a defect?

BTW thermal problems are not that issue, as long as you have the cure to 
measure temperature along your time measurement. With this information 
you can correct your values with a correct calibration procedure.

> Keep in mind that you will have jitter introduced for:
> 
> 1. Clock / signal input indeterminacy. At some point, you have to 
> capture your signal. The FF will switch somewhere in the indeterminate 
> region. The slower your input source, the worse this is. You can't 
> expect a FF to switch at the same level two consecutive times either, 
> although usually adjacent clocks will switch at a close level. 
> Estimation of that jitter depends on the technology you are using.
> 
> 2. Oscillator jitter. There will always be jitter on an oscillator. It 
> might be low, but you can't get rid of it.
> 
> 3. Possible metastability. This afflicts all FFs, and although it can be 
> worked around, you should be aware of it. (It's not a high level issue, 
> but it does exist - there was a thread on it recently)

All these warnings are related to a synchronous logic approach, which is 
not what I will use, and which is not desirable at all in any time 
measurement to me.
> 
> 4. PCB routing. All PCBs will exhibit deterministic jitter (which can be 
> calculated). This will be made worse if you have vias on highspeed nets 
> (which can be alleviated somewhat with differential techniques I won't 
> go into here). Unless you are using waveguide or optical techniques (and 
> even they suffer from jitter too) you'll have a low pass filter 
> introducing jitter. Then there's track adjacency, impulse response of 
> the power etc.

PCB routing is not a major issue because with a good calibration 
procedure you can live with it.

> 
> I have seen a single via add 50ps of deterministic jitter on fast 
> signals (edge rate about 10^4V/us) on FR4-13. I have no idea what PCB 
> material you are using or intend to use, but keep this in mind.

Could you better explain what do you really mean by deterministic jitter 
in this case?
> 
> Another issue of importance is which form of jitter is your biggest 
> issue: Cycle to cycle? rms? peak to peak? long term (sometimes known as 
> frequency drift)
> 
> Some food for thought.

The more food we have the better results we get!
> 
> Cheers
> 
> PeteS


-- 
Alessandro Basili
CERN, PH/UGC
Hardware Designer

Article: 112361
Subject: Re: pulse jitter due to clock
From: "Symon" <symon_brewer@hotmail.com>
Date: Tue, 21 Nov 2006 09:53:14 -0000
Links: << >>  << T >>  << A >>
"Al" <alessandro.basili@cern.ch> wrote in message 
news:ejugts$gj9$1@cernne03.cern.ch...
>
> Could you better explain what do you really mean by deterministic jitter 
> in this case?
>
C'mon Al, CERN invented the WWW! :-) The first hit from Google explains it 
all!

I think the problem with FPGAs is that the leakage and thermal noise 
together with the internal single ended signals all conspire to add jitter 
to your signal. It doesn't help that the output rise time is, I guess, at 
best 500ps depending on what you're driving.
You might like to consider a crosspoint switch solution. I think Mindspeed 
and Vitesse might have something you could use.

e.g. 
http://www.commsdesign.com/new_products/showArticle.jhtml?articleID=16503342

These parts are used in SONET (SDH where you are!) systems which have very 
tight jitter specs. Right up your street!

Good luck, Syms.




Article: 112362
Subject: Re: Simple questions on IDELAYCTRL
From: Sean Durkin <smd@despammed.com>
Date: Tue, 21 Nov 2006 10:56:09 +0100
Links: << >>  << T >>  << A >>
lecroy7200@chek.com wrote:
> I can't seem to find a document that calls out the XY locations for the
> IDELAYCTRL.  Where is this information found?
Try Jim Wu's free ADEPT-Tool:
http://home.comcast.net/~jimwu88/tools/adept/

There's a view where you can see the IDELAYCTRL-locations and the pins
that are controlled by this specific IDELAYCTRL. This tools is really
handy for other stuff as well (like seeing which IOs belong to which
IO-Clock-Region and regional clock and things like that), and doesn't
cost anything.

cu,
Sean

Article: 112363
Subject: Spartan-3E Starter Kit and programmable pre-Amplifier
From: "=?utf-8?B?R2FMYUt0SWtVc+KEog==?=" <taileb.mehdi@gmail.com>
Date: 21 Nov 2006 02:25:43 -0800
Links: << >>  << T >>  << A >>
Hi,
In the ug230.pdf (user guide for Spartan-3E Starter Kit) page.76,
figure 10-4 the timing caracteristics of the SPI interface of the
LTC6912-1 pre-amplifier are the following:
 - SPI_SCK LOW=50ns
 - SPI_SCK HIGH=50ns
 - AMP_CS LOW to SPI_SCK=30ns
 - SPI_MOSI VALID to SPI_SCK SETUP=30ns
 - AMP_DOUT OUTPUT DELAY=85ns

When I look at the schematics of the ADC/DAC part of the board
(ug230.pdf, p.151) I see than V+=3.3V and V-=0V for the pre-amplifier.

I took a look at the LTC6912-1 datasheet (got from the link on page 79
in ug230.pdf) and on page 11 in the section "SERIAL INTERFACE
SPECIFICATION" I see that for V+=2.7V~4.5V the following timing
parameters should be used:
 - CLK (== SPI_SCK) LOW=100ns
 - CLK (== SPI_SCK) HIGH=100ns
 - CS/LD (==AMP_CS) LOW to CLK (== SPI_SCK)=30ns
 - DIN VALID to CLK (== SPI_SCK) SETUP=60ns
 - DOUT (== AMP_DOUT) OUTPUT DELAY=125ns

Can anyone (preferably from Xilinx) explain me if it's some
miscomprehension from me or if there is some error in the documentation
and if so than please tell me which parameters should I take into
consideration.

Best Regards
Mehdi TAILEB


Article: 112364
Subject: Re: pulse jitter due to clock
From: Al <alessandro.basili@cern.ch>
Date: Tue, 21 Nov 2006 11:44:06 +0100
Links: << >>  << T >>  << A >>
Symon wrote:
> 
> C'mon Al, CERN invented the WWW! :-) The first hit from Google explains it 
> all!
> 
So what? didn't get it.

> I think the problem with FPGAs is that the leakage and thermal noise 
> together with the internal single ended signals all conspire to add jitter 
> to your signal. It doesn't help that the output rise time is, I guess, at 
> best 500ps depending on what you're driving.

Rise time doesn't involve jitter, as long as it is fixed. Maybe we 
should agree on what does jitter mean.

> You might like to consider a crosspoint switch solution. I think Mindspeed 
> and Vitesse might have something you could use.

Maybe this is a good alternative, which maight have been used. 
Unfortunately the power consumption is something like 2.5 Watts for a 
500 MHz BW chip. Consider that our DSP boards which holds 2 FPGAs, a 
DSP, a Ram chip and a Flash chip and run with 4 simultaneous link at 100 
Mbits each will reach up to 1.2 Watts only.
Unfortunately power budget is mandatory in our case, moreover we need 
have 5 channels per board and 20 boards, so it will soon reach a power 
budget that is not really acceptable.

Another main problem with this stuff is to find out reliability in a 
radiation environment, how will they behave? how long will they last? 
Maybe someone have some experience and did some rad-hard test with these 
type of chips.

Thanks for the suggetion anyway!

Cheers

Al


-- 
Alessandro Basili
CERN, PH/UGC
Hardware Designer

Article: 112365
Subject: Re: pulse jitter due to clock
From: "Symon" <symon_brewer@hotmail.com>
Date: Tue, 21 Nov 2006 11:26:44 -0000
Links: << >>  << T >>  << A >>
"Al" <alessandro.basili@cern.ch> wrote in message 
news:ejul8l$iv7$1@cernne03.cern.ch...
> Symon wrote:
>>
>> C'mon Al, CERN invented the WWW! :-) The first hit from Google explains 
>> it all!
>>
> So what? didn't get it.
>
Well, actually you mightn't need to understand it; as Kolja posted, if your 
application is one-shot, so there's no ISI which would produce deterministic 
jitter in your system. Seriously, there's plenty of stuff online that 
explains the differences and sources between the different types of jitter.
>
> Rise time doesn't involve jitter, as long as it is fixed.
OK, think about the receive end, as the signal rises through the switching 
threshold. Voltage noise adds more time jitter to a slow rising signal than 
to a fast rising one. That's my point and is why rise time is important.

>

> Maybe we should agree on what does jitter mean.
>

Google gives:-
The deviation from the ideal timing of an event.

HTH, Syms. 



Article: 112366
Subject: Re: DDR_SDRAM_VHDL_models
From: "subint" <subin.82@gmail.com>
Date: 21 Nov 2006 03:43:40 -0800
Links: << >>  << T >>  << A >>
Download the MIG tool from xilnx to generate the DDR SDRAM controller
..
subin
Vangelis wrote:
> Does anynone know where can I find VHDL models for DDR-I SDRAM modules? I have an XUP board and I want to run some simulations before downloading my design to the FPGA. I am not looking for a specific model. Any generic DDR-I SDRAM model will do the job.


Article: 112367
Subject: Re: pulse jitter due to clock
From: Al <alessandro.basili@cern.ch>
Date: Tue, 21 Nov 2006 13:34:06 +0100
Links: << >>  << T >>  << A >>
Symon wrote:
> Well, actually you mightn't need to understand it; as Kolja posted, if your 
> application is one-shot, so there's no ISI which would produce deterministic 
> jitter in your system. Seriously, there's plenty of stuff online that 
> explains the differences and sources between the different types of jitter.
> 
>>Rise time doesn't involve jitter, as long as it is fixed.
> 
> OK, think about the receive end, as the signal rises through the switching 
> threshold. Voltage noise adds more time jitter to a slow rising signal than 
> to a fast rising one. That's my point and is why rise time is important.
> 
Thinking about receiving end, what is easier to have: a much stable 
voltage or a faster signal? How much power will you need to have a 
faster signal? Then if you are worried about voltage noise, then I 
ensure you that time induced jitter is easily evaluated with the 
following formula:

T-noise = V-noise/rise-time

reducing rise-time has the same gain of reducing V-noise.

Moreover a faster rise-time can easily come with a variable 
propagation-delay, just because you moved the critical point on another 
component, which still has a voltage-reference to be crossed and an 
input stage to be loaded.
> 
> 
>>Maybe we should agree on what does jitter mean.
>>
> 
> 
> Google gives:-
> The deviation from the ideal timing of an event.
> 

I don't think is quite an explanation, what does "ideal" means? Does it 
mean with "ideal" components? Still there will be a "jitter" depending 
on how you produce the signal and depending on how you "sample" the 
signal, ever heard about digitization noise?
What "deviation" means? I hope this deviation will have a distribution, 
otherwise is not a deviation, but is better to call it delay. If all the 
components in the measurement chain will have a "deviation from the 
ideal timing of an event" you can still have an "ideal timing of the 
event" if all the "deviations" turns out to be delays.

The reference you pick this definition from is most likely the same one 
which says:
"Jitter is composed of both deterministic and Gaussian"

well, this is much more confusing than other definition. Does 
deterministic jitter has a distribution? no? so why don't you just call 
it delay. Still if something _has_ a distribution it _can_ be 
deterministic the same, have you ever heard about notch filters? Aren't 
they cutting off a deterministic range of a noise spectra?

To my point of you I still believe we are not talking about the same thing.



> HTH, Syms. 
> 
> 


-- 
Alessandro Basili
CERN, PH/UGC
Hardware Designer

Article: 112368
Subject: Re: pulse jitter due to clock
From: Al <alessandro.basili@cern.ch>
Date: Tue, 21 Nov 2006 14:25:26 +0100
Links: << >>  << T >>  << A >>
A correction to my previous post

Al wrote:
> The reference you pick this definition from is most likely the same one 
> which says:
> "Jitter is composed of both deterministic and Gaussian"
> 
I didn't read the whole document 
(http://wavecrestcorp.com/technical/VISI_6_Getting_Started_Guides/6understanding.PDF), 
but still it goes through data and clock receiving matters which are far 
away this topic (InterSymbol interference, duty cycle distorsion, etc.).
Sorry about that
Al

-- 
Alessandro Basili
CERN, PH/UGC
Hardware Designer

Article: 112369
Subject: Re: 8080 FSGA model in an FPGA
From: "rickman" <gnuarm@gmail.com>
Date: 21 Nov 2006 05:40:46 -0800
Links: << >>  << T >>  << A >>
Grant Stockly wrote:
> Ray Andraka wrote:
> > Jon Elson wrote:
> >
> >
> > Some people have way too much time on their hands!
>
> I want to use the transistor board set as part of a possible computer
> kit / electronics trainer.  I have just completed the Altair Kit
> reproduction that I've been working on for 9 months as a hobby.  If I
> can stick with it and get that done on my time off, I think a
> transistor 8080 would be easy.  ;)
>
> http://www.altairkit.com
> http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=250052265051
>
> Any way, I guess I would be happy if the transistor computer were
> instruction set compatible AND timing compatible.  I really am not
> concerned about how the computer is constructed at the transistor
> level, but I want the status signals the same and the instruction set
> cycle count to be the same.  If a program depends on a software delay
> loop, I would want it to be equal.
>
> Maybe I'm trying to attempt too much.  I think my best bet is to
> reasearch the 9080 emulator by AMD and duplicate that.  Its possible I
> could rewrite the microcode to include status bit states.  Who knows...
>
> With this new information, does anyone see a different easier path?  Or
> am I still just plain crazy?  :)  I won't be making any transistor
> 8080s until I'm out from under all the investments in the Altair
> project!

If you are just trying to build a trainer of some sort, wouldn't it be
easier to build a simulation that could show all the internal states?
It has got to be easier to do a simulation than a construction project
from transistors or even from CPLDs.


Article: 112370
Subject: Re: pulse jitter due to clock
From: John_H <newsgroup@johnhandwork.com>
Date: Tue, 21 Nov 2006 14:33:04 GMT
Links: << >>  << T >>  << A >>
Al wrote:
> Hi to everyone,
> I'm developing some electronics to make a time measurement with a 
> resolution of 25 ps. I'm using a dedicated ASIC to do so but I'm giving 
> the signals to the ASIC through an FPGA.
> The way is very simple, basically I have some signals coming to my fpga 
> which I will mask with some combinatorial logic and a configurable 
> register so that I can allow some measurements or some others. The 
> output of this "masking" will go to the ASIC.
> They assert (and here is the question) that a clocked device as an FPGA 
> may add some jitter to the signals due to the substrate  current 
> overload (for the presence of the clock) that will lead to some 15 ps 
> jitter over the signals. I don't know how they could resolve this value 
> but I'm assuming they were telling the truth about numbers (at least, 
> while I have some doubts about explanation of those numbers).
> Can anyone say something about this? Does it sound reasonable?
> 
> Al

If you pass your trigger through the FPGA, your measurement can be off 
by +/- hundreds of picoseconds from one measurement to the next.  Over 
many measurements your gaussian jitter will be increased by a 
substantial amount only because of the jitter.

Using a complex trigger condition through an FPGA doesn't mean you have 
to measure the signal coming out of the FPGA.  Generate the mask in the 
FPGA and use it to gate the original (always on) trigger signal the 
measurement is performed on.  You chooses the edge(s) to analyze but 
through a very clean external gate unaffected by the jitter-laden mask 
signal coming from the FPGA.

If you insist on analyzing the signal leaving the FPGA, please let me 
know the company you're working for so I can avoid considering your 
products for any future needs.

Article: 112371
Subject: Re: pulse jitter due to clock
From: "Symon" <symon_brewer@hotmail.com>
Date: Tue, 21 Nov 2006 14:37:54 -0000
Links: << >>  << T >>  << A >>
"Al" <alessandro.basili@cern.ch> wrote in message 
news:ejul8l$iv7$1@cernne03.cern.ch...
> Symon wrote:
>
>> You might like to consider a crosspoint switch solution. I think 
>> Mindspeed and Vitesse might have something you could use.
>
> Maybe this is a good alternative, which maight have been used. 
> Unfortunately the power consumption is something like 2.5 Watts for a 500 
> MHz BW chip. Consider that our DSP boards which holds 2 FPGAs, a DSP, a 
> Ram chip and a Flash chip and run with 4 simultaneous link at 100 Mbits 
> each will reach up to 1.2 Watts only.
> Unfortunately power budget is mandatory in our case, moreover we need have 
> 5 channels per board and 20 boards, so it will soon reach a power budget 
> that is not really acceptable.
>
Hi Al,
Well, after thinking about your requirements, I guess the best solution to 
you is to switch the signals with PIN diodes. Like this:-

http://www.radio-electronics.com/info/circuits/diode_simple_attenuator/diode_attenuator.php

The diode's resistance when it's on is of the order of an ohm or two, so 
they're very low noise, much better than GaAs fets. (My microwave engineer 
buddy has a big downer on GaAs switches, they blow up too easily and they're 
more noisy.) You can probably get away with connecting a whole bunch of PIN 
diode switches together as you're only looking for a one shot type deal, so 
reflections aren't too big a problem. As only one diode will be on at any 
one time, the others being reverse biased, it'll be the only one using 
current, so you only need about 5ma or so.
I guess PIN diodes are good at radiation, what's to go wrong?
HTH, Syms.



Article: 112372
Subject: Re: Compiling Linux Kernel for ML405
From: Peter Mendham <petermendham@NOCANNEDMEAT.computing.dundee.ac.uk>
Date: Tue, 21 Nov 2006 15:11:55 +0000
Links: << >>  << T >>  << A >>
Hi,

Sorry for the delay in replying, I'm juggling a couple of projects and 
had to leave this for a few days.  Thank you for your excellent advice, 
I now have a booting kernel -- thanks!

> not sure why, but it sounds like the Makefile in the
> arch/ppc/platforms/xilinx_ocp directory didn't get regenerated after
> you modified xilinx_syms.c

Hmmm, I don't understand either but the Makefile was clearly at fault. 
The Makefile seems to be part of the source tree.  A modified makefile 
should maybe be part of the BSP(?) but it isn't.

> you could try making the modification to a virgin copy of the source
> tree before running make menuconfig, make dep, etc...  the Makefile
> should look something like this:

I actually did a make distclean then modified the makefile by hand. make 
dep did not seem to touch the makefile, I gues it uses it(?) I only had 
one slight issue with the Makefile, I don't have any of the xdmav* 
targets, should I?

> # Makefile for the Xilinx On Chip Peripheral support code
> #
> 
> list-multi              := xilinx_ocp.o
> 
> # Linux file to EXPORT_SYMBOL all of the Xilinx entries.
> export-objs             += xilinx_syms.o
> xilinx_ocp-objs         += xilinx_syms.o
> 
> # The Xilinx OS independent code.
> xilinx_ocp-objs         += xbasic_types.o xdma_channel.o
> xdma_channel_sg.o \
>                            xdmav3.o  xdmav3_intr.o  xdmav3_selftest.o
> xdmav3_sg.o \
>                            xipif_v1_23_b.o xpacket_fifo_v2_00_a.o \
>                            xpacket_fifo_l_v2_00_a.o xversion.o
> 
> obj-$(CONFIG_XILINX_OCP) := xilinx_ocp.o
> 
> xilinx_ocp.o: $(xilinx_ocp-objs)
>         $(LD) -r -o $@ $(xilinx_ocp-objs)
> 
> include $(TOPDIR)/Rules.make

I confess that I had one more issue when building, it appears that the 
functions XIic_Recv and XIic_Send (from drivers/i2c/xilinx_iic/xiic_l.c) 
now have one more parameter.  I had to modify the calls in 
arch/ppc/boot/simple/embed_config.c to include this extra parameter 
which I specified as XIIC_STOP (instructs the I2C driver to release the 
bus after the transaction).  Not sure if this is right (I know nothing 
about I2C) but it seems to work... ;)

Thanks again, and I hope this post is of some use to others out there 
attempting the same thing,

-- Peter

Article: 112373
Subject: Re: memory init in Altera bitfiles, (like data2mem) is it possible?
From: "radarman" <jshamlet@gmail.com>
Date: 21 Nov 2006 07:20:21 -0800
Links: << >>  << T >>  << A >>

already5chosen@yahoo.com wrote:
> radarman wrote:
>
> > This is all well and good, but even with smart compilation turned on,
> > things don't work quite as well as they should. I'm designing my own
> > CPU core, so I'm not using NIOS, but I still need to be able to update
> > BRAM's with new program code.
> >
> > I've already worked around (sort of) the fact that for some reason,
> > Quartus won't properly update a BRAM from a .hex file. (.hex files work
> > fine for compilation, but not a mif/hex update. So, I bring my .hex
> > file into Quartus, and save it as a .mif file.  This is annoying, since
> > I can no longer automate the whole build process. At some point, when I
> > get irritated enough, I'll write a program that converts hex to mif
> > correctly, but I haven't had the time for much extra programming
> > lately.
> >
> > However, the MORE irritating problem I've run into is that if I repeat
> > the mif/hex update process a second time, changing only the .mif file,
> > Quartus launches into a full recompile anyway. This is a bit
> > frustrating, since the "hardware" is stable at this point. I just need
> > to test software. Perhaps I've missed something, but I've yet to find a
> > way to avoid the full recompile on the second update.
> >
> > Maybe this works correctly in the NIOS flow, but I don't have that tool
> > available. I did try the NIOS eval, though, and I didn't see any new
> > tools in it that looked like they would solve my problem.
>
>
> What version of Quartus? Service pack? Critical update?
> Sounds like you were hit by that:
> http://www.altera.com/support/kdb/solutions/rd03062006_72.html
>
> BTW, if you want to minimize troubles please store you .hex files in
> Quartus project directory.

I first noticed the problem in 5.1 SP2, but have since updated to 6.0
SP1. I already store the init files in the project folder - it's
automatically copied as part of the build scripts.

Note, my projects aren't failing (they run properly), I just have to
sit through a full recompile every second update.

However, this might explain some curious behavior I was seeing before I
upgraded to 6.0. My processor would occasionally hang on the first JSR
instruction after doing an incremental compilation. I suspected that
the memory wasn't workiing correctly, but it never occurred to me that
the tool might be at fault. I thougt that perhaps I had set something
up incorrectly - since the ROM appeared to be working just fine. (my
design has a 16kB instruction ROM, and 32kB data RAM - both megawizard
created)

That support answer appears to explain what was going on.


Article: 112374
Subject: Re: pulse jitter due to clock
From: Al <alessandro.basili@cern.ch>
Date: Tue, 21 Nov 2006 16:27:52 +0100
Links: << >>  << T >>  << A >>
Symon wrote:
> Hi Al,
> Well, after thinking about your requirements, I guess the best solution to 
> you is to switch the signals with PIN diodes. Like this:-
> 
> http://www.radio-electronics.com/info/circuits/diode_simple_attenuator/diode_attenuator.php
> 
> The diode's resistance when it's on is of the order of an ohm or two, so 
> they're very low noise, much better than GaAs fets. (My microwave engineer 
> buddy has a big downer on GaAs switches, they blow up too easily and they're 
> more noisy.) You can probably get away with connecting a whole bunch of PIN 
> diode switches together as you're only looking for a one shot type deal, so 
> reflections aren't too big a problem. As only one diode will be on at any 
> one time, the others being reverse biased, it'll be the only one using 
> current, so you only need about 5ma or so.
> I guess PIN diodes are good at radiation, what's to go wrong?
> HTH, Syms.
> 
> 

I think that could be a good solution too, maybe next project!
Regards

Al


-- 
Alessandro Basili
CERN, PH/UGC
Hardware Designer



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