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 121200

Article: 121200
Subject: Re: another Forth CPU design
From: Frank Buss <fb@frank-buss.de>
Date: Thu, 28 Jun 2007 07:32:48 +0200
Links: << >>  << T >>  << A >>
Jim Granville wrote:

> With a simple core, that is not clock constrained (ie spare cycles at 
> the core), how feasible is it to time-share that core, with two 
> code/data streams, so effectively you see two independant 
> 'multi-processor' cores ?

This should be easy. The only states in the core are A, SP, RP and PC,
which have to be swapped.

But instead doing it on the hardware level, I think it would be better to
do it in software: First the CPU needs to be enhanced to allow interrupts
and to load/save the SP and RP registers. Then you can implement a
scheduler for as many threads you want.

> Not sure if I have mentioned IEC 61131 Instruction List pgm before, but
> this looks fairly close to that.

I don't know IL, but it looks a bit too low-level. Creating a function like
decribed at http://www.61131.com/il.htm would look like this in Forth (the
stack notation in parantheses ( s _r -- ) is only a comment and can be
omitted)

value q
: sr ( s _r -- ) q and or to q ;

Then you can test it interactively at the Forth command prompt ("q ." shows
the current value of q. Anything after "\" in a line is comment)

1 1 sr q . \ set flipflop
1  ok

0 1 sr q . \ set input = 0 => q is not changed
1  ok

0 0 sr q . \ reset flipflop
0  ok

Maybe an IL core could be a bit smaller, because it doesn't have a data
stack, but I think programs would be larger and are more difficult to write
and maintain than Forth programs.

-- 
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de

Article: 121201
Subject: Re: Coding style of verilog for FPGA synthesis
From: ghelbig@lycos.com
Date: Wed, 27 Jun 2007 22:57:17 -0700
Links: << >>  << T >>  << A >>
On Jun 25, 10:59 pm, Allen <lphp...@gmail.com> wrote:
> hi, guys
>
> We design a hardware written in Verilog and synthesize by Synopsys
> Design Vision.
>
> The post-synthesis simulation is shown that the function of hardware
> is correct.
>
> Now, we are going to verify function of hardware by downloading it to
> Xilinx FPGA.
>
> We synthsize the hardware design by using ISE 7.1i. Unfortunately, the
> post-synthesis simulation failed ( all the output is unknown or high-
> impeadance). I tried to synthesize with keeping hierarchy, but it
> still unuseful.
>
> What can I do next step? We don't have much experience in this field.
>
> Thanks.
>
> Regards

It could be that you don't have it connected properly in your test
bench.

If all of the outputs are unknown, then the inputs are probably
unknown too.

Some probing with your simulator should find it.  I'd start with clock
& reset.

G.


Article: 121202
Subject: Re: Bit error counter - how to make it faster
From: Ben Jackson <ben@ben.com>
Date: Thu, 28 Jun 2007 02:21:55 -0500
Links: << >>  << T >>  << A >>
On 2007-06-27, gamer <csanjay@gmail.com> wrote:
>    else if (~matched)
>       for (i=0; i<datawidth; i=i+1)
>          error_count = error_count + mismatch[i];

Although from a software (and possibly a simulation) perspective, that
looks like it should reduce the workload by computing 'matched' and
"avoiding" the loop if it is not needed, in hardware your speed is
going to be limited by the worst case (and the additions are happening
all the time, only the enables on the error_count register are affected
by your 'if').

If you must have your answer on the very next clock, your options are
severely limited.  If you only care about the answer occasionally (or
with a fixed latency that's greater than one clock), think about how
you can take advantage of that.

To follow along your original lines of thinking:  If you can really find
'matched' at your desired clockrate, and it is infrequent, then you could
stuff 'mismatch' into a fifo whenever it's nonzero and add it in a
separate loop which only has to keep up with the worst case bit error
rate.

Or, if, as you said, the process is fast enough for 1 bit, make yourself
'datawidth' 1-bit error counters and add their results whenever you want
the total number of errors.

-- 
Ben Jackson AD7GD
<ben@ben.com>
http://www.ben.com/

Article: 121203
Subject: Re: another Forth CPU design
From: Jim Granville <no.spam@designtools.maps.co.nz>
Date: Thu, 28 Jun 2007 19:55:22 +1200
Links: << >>  << T >>  << A >>
Frank Buss wrote:
> Jim Granville wrote:
> 
> 
>>With a simple core, that is not clock constrained (ie spare cycles at 
>>the core), how feasible is it to time-share that core, with two 
>>code/data streams, so effectively you see two independant 
>>'multi-processor' cores ?
> 
> 
> This should be easy. The only states in the core are A, SP, RP and PC,
> which have to be swapped.
> 
> But instead doing it on the hardware level, I think it would be better to
> do it in software: First the CPU needs to be enhanced to allow interrupts
> and to load/save the SP and RP registers. Then you can implement a
> scheduler for as many threads you want.

That's the more conventional way, but I like the deterministic nature of 
hardware time-sliced cores - and they can of course, also run interrupts 
(giving SW threads on the HW threads.. :).

The problem with interrupts, is the more complex a system is, the bigger 
the jitters become. With HW timeslice, each task is invisible to the 
other, in the time domain, and they need to share some data to communicate.


> 
>>Not sure if I have mentioned IEC 61131 Instruction List pgm before, but
>>this looks fairly close to that.
> 
> 
> I don't know IL, but it looks a bit too low-level. Creating a function like
> decribed at http://www.61131.com/il.htm would look like this in Forth (the
> stack notation in parantheses ( s _r -- ) is only a comment and can be
> omitted)
> 
> value q
> : sr ( s _r -- ) q and or to q ;
> 
> Then you can test it interactively at the Forth command prompt ("q ." shows
> the current value of q. Anything after "\" in a line is comment)
> 
> 1 1 sr q . \ set flipflop
> 1  ok
> 
> 0 1 sr q . \ set input = 0 => q is not changed
> 1  ok
> 
> 0 0 sr q . \ reset flipflop
> 0  ok
> 
> Maybe an IL core could be a bit smaller, because it doesn't have a data
> stack, but I think programs would be larger and are more difficult to write
> and maintain than Forth programs.

IL does allow brackets, and expressions inside the brackets evaluate 
first, just like in maths, and that gives a Data Stack.
So the IL 'Assembler/Compiler' would have to generate the opcodes to
support the stack to support the brackets.

-jg


Article: 121204
Subject: Re: Xilinx FPGA to interface to special I/O
From: Ben Jackson <ben@ben.com>
Date: Thu, 28 Jun 2007 02:56:13 -0500
Links: << >>  << T >>  << A >>
On 2007-06-28, Albert Nguyen <> wrote:
> I have a specific application where the FPGA needs to generate SPI
>
> The problem is that the traget device will have its vcc at 1.2V and and its Vee at -1.3V.

All SPI signals are unidirectional, so you should be able to level shift
with a few transistors.  Why not:

                 Vcc
                  +
                  |
                  |
          1k_   |<
 [SCK>---|___|--|
                |\     |
                  o-------.
                 .-.      |
                 | |   | ---
              500| |     --- 10p "load"
                 '-'   |  |
                  o-------'
                  |    |
                 ===
                 Vee


SCK high is > 1.2V, SCK low < 1.2V.  Be sure to park SCK low, and invert
the signals...

(created by AACircuit v1.28.6 beta 04/19/05 www.tech-chat.de)

-- 
Ben Jackson AD7GD
<ben@ben.com>
http://www.ben.com/

Article: 121205
Subject: Re: Xilinx Modelsim XE-III 6.2g no more Systemverilog support?
From: "HT-Lab" <hans64@ht-lab.com>
Date: Thu, 28 Jun 2007 08:06:53 GMT
Links: << >>  << T >>  << A >>

"Xilinx User" <anonymous@net.com> wrote in message 
news:h1Dgi.4487$vi5.1602@newssvr17.news.prodigy.net...
snip
> i was going to suggest buying a few XE-III (full) licenses,
> but that was contingent upon, apparently, an
> undocumented/unofficial support for Systemverilog.  Now,
> I'll probably suggest getting (Mentor) Modelsim-PE.
>
> Anyway, Modelsim XE-III 6.2c starter-edition ran
> Systemverilog simulations just fine.  So did Xilinx remove
> this feature from XE-III 6.2g?  Nowhere in Xilinx's
> online documentation, does Xilinx claim to support
> Systemverilog.  But I'd like to get a definitive/official
> answer.

If this is indeed the case then I believe Mentor has changed their OEM 
agreement with Xilinx since the difference has always been simulation speed 
and number of instances.

This might just been an oversight on Xilinx's part?

Do you have the sv_std folder in your installation directory? (I have it on 
my PE installation).

Hans
www.ht-lab.com



Article: 121206
Subject: Analogue like signal interaction within cpld possible ????
From: "Ulrich Bangert" <df6jb@ulrich-bangert.de>
Date: Thu, 28 Jun 2007 11:02:38 +0200
Links: << >>  << T >>  << A >>
Gents,

please allow me to confront you with some strange timing behaviour which I
have measured with an Xilinx  XC95108 cpld.

Consider two well conditioned clock signals of 10 MHz (both having EXACTLY
the same frequency) entering the cpld. Inside the cpld each clock signal is
divided by 4 by means of two d-flip-flops. The two resulting 2.5 Mhz signals
enter an exclusive-or-gate which delivers an output signal where the
pulse/pause-relationship directly depends on the phase relationship of the
two input clocks.

If some of you feel reminded to something that you have seen before: Yes,
basically this is the principle of an so called linear phase comparator
which has been used to compare high stability clocks (for example cesium
clocks) against each other before high resolution time interval counters
like the HP5370 or the Stanford Research SR620 were available.

Now imagine one of the two clocks is de-tuned by exactly 0.001 Hz. It is a
bit beyond the discussion HOW this is achieved but you may believe me that
this is possible and that THIS is not part of the discussed problem. Now the
phase relationship of the clocks changes slowly in time as does the
pulse/pause relationship behind the xor gate. The pulse/pause relationship
of the xor's output can be measured by two completely different methods:

a) by generating an dc voltage which is directly proportional to the
pulse/pause relationship (again a bit tricky if you want it to be an really
high resolution measurement, but it  can  be done)

b) by directly measuring the output pulse width with an high resolution time
interval counter like the SR620 having a 25 ps single shot resolution for
time interval measurements.

It is important to note that both methods to measure can be applied at the
same time and that both methods (although based on completely different
physical laws) deliver results that despite some statistical fluctuations
are basically the same. That is why I am pretty sure that what I measure is
really an property of the signal itself and not one of the measurement
apparatus.

If I record the pulse width over time using the two methods and display it
graphically it looks like an pretty linear relationship at the first glance.
If however some math is applied to make it evident how good the linear
relationship really is met then the result is that there are fluctuations in
the pulse width in the order of some +/-450 ps from the expected values.

About these fluctuations the following facts are known:

1) They are not existent in the inputs clocks

2) Expressed in time units as well as expressed as an dc voltage the
fluctuations are orders of magnitude bigger than the resolution and
precision of the time/dc measurement.

3) The fluctuations are by no means of stochastical nature. Instead, If an
positive fluctuation is noticed at an certain phase between the clock
signals, an fluctuation of the same magnitude and sign  will be noticed  the
next time when the clock signals have the same phase relationship. Or in
other words: The pulse width is an direct function of the phase relationship
of the clocks + an error function which is an direct function of the phase
relationship between the clocks.

It seems as if the phase state of one of the signals can have an linear like
modulating effect on the phase state of the second signal (and perhaps vice
versa). Some of you may come to the conclusion that +/-450 ps is not an
number to cause real world troubles but in my case: The whole arrangement
has the intention to measure phase fluctuations of the input clocks that ARE
REALLY THERE but that are smaller at least one order of magnitude than the
noticed errors. And that is why +/-450 ps is an real annoying number for me.

Any hint will be highly appreciated
TIA, Ulrich Bangert





Article: 121207
Subject: ISE 9.1 Problem
From: "maxascent" <maxascent@yahoo.co.uk>
Date: Thu, 28 Jun 2007 04:24:22 -0500
Links: << >>  << T >>  << A >>

Hi 

Can anyone tell me what Xilinx have done to the timing summary in ISE 9.1.
In 8.2 it used to give you what you requested and by how much it was met.
In 9.1 it has changed with reference to MAXDELAY which I have not even
set.

Cheers 

Jon

Article: 121208
Subject: Re: How to create simple design?
From: <xtr>
Date: Thu, 28 Jun 2007 11:29:41 +0100
Links: << >>  << T >>  << A >>
Thank you for kind offer, but I have managed it.
There was some problem with the ide, which
crashed at the very end the first time round, something
error in line 570 very dubious, but then I just did it
again with a new project and it did work. I shall need
some help with my programmer, maybe you will be
available, I am waiting for it to arrive from my ebay
seller.
BTW, how did you learn how to use the schematic
editor?

...and what is the difference between and2 and2b1 and2b2
Thanks
Arlen




> Be sure to place I/O markers at the input and outputs.  Otherwise,
> you will get an error.  Highlight the top level schematic in
> the source window. In the process window below expand
> 'User Constraints' and double click 'Assign package pins'.
> Answer 'Yes' to create constraint file.  The program
> Xilinx Pace should start.  In the 'Design Browser' window
> expand the 'I/O Pins' tree list.  Drag each pin to the
> desired available I/O pin.  Save and close.
> You can implement a design without assigning pins.  It will
> automatically place the I/O pins at the most effecient
> place.  This is useful when designing a new board, and you
> want optimun placement and performance.
>
> Ensure the top level schematic is still highlighted.
> In the process window double click 'Implement Design'.
>
> Review the log window below for any errors.
>
> I can email you a zipped AND gate project if you want!



Article: 121209
Subject: Re: Analogue like signal interaction within cpld possible ????
From: Jim Granville <no.spam@designtools.maps.co.nz>
Date: Thu, 28 Jun 2007 23:00:54 +1200
Links: << >>  << T >>  << A >>
Ulrich Bangert wrote:
> Gents,
> 
> please allow me to confront you with some strange timing behaviour which I
> have measured with an Xilinx  XC95108 cpld.
> 
> Consider two well conditioned clock signals of 10 MHz (both having EXACTLY
> the same frequency) entering the cpld. Inside the cpld each clock signal is
> divided by 4 by means of two d-flip-flops. The two resulting 2.5 Mhz signals
> enter an exclusive-or-gate which delivers an output signal where the
> pulse/pause-relationship directly depends on the phase relationship of the
> two input clocks.
> 
> If some of you feel reminded to something that you have seen before: Yes,
> basically this is the principle of an so called linear phase comparator
> which has been used to compare high stability clocks (for example cesium
> clocks) against each other before high resolution time interval counters
> like the HP5370 or the Stanford Research SR620 were available.
> 
> Now imagine one of the two clocks is de-tuned by exactly 0.001 Hz. It is a
> bit beyond the discussion HOW this is achieved but you may believe me that
> this is possible and that THIS is not part of the discussed problem. Now the
> phase relationship of the clocks changes slowly in time as does the
> pulse/pause relationship behind the xor gate. The pulse/pause relationship
> of the xor's output can be measured by two completely different methods:
> 
> a) by generating an dc voltage which is directly proportional to the
> pulse/pause relationship (again a bit tricky if you want it to be an really
> high resolution measurement, but it  can  be done)
> 
> b) by directly measuring the output pulse width with an high resolution time
> interval counter like the SR620 having a 25 ps single shot resolution for
> time interval measurements.
> 
> It is important to note that both methods to measure can be applied at the
> same time and that both methods (although based on completely different
> physical laws) deliver results that despite some statistical fluctuations
> are basically the same. That is why I am pretty sure that what I measure is
> really an property of the signal itself and not one of the measurement
> apparatus.
> 
> If I record the pulse width over time using the two methods and display it
> graphically it looks like an pretty linear relationship at the first glance.
> If however some math is applied to make it evident how good the linear
> relationship really is met then the result is that there are fluctuations in
> the pulse width in the order of some +/-450 ps from the expected values.
> 
> About these fluctuations the following facts are known:
> 
> 1) They are not existent in the inputs clocks
> 
> 2) Expressed in time units as well as expressed as an dc voltage the
> fluctuations are orders of magnitude bigger than the resolution and
> precision of the time/dc measurement.
> 
> 3) The fluctuations are by no means of stochastical nature. Instead, If an
> positive fluctuation is noticed at an certain phase between the clock
> signals, an fluctuation of the same magnitude and sign  will be noticed  the
> next time when the clock signals have the same phase relationship. Or in
> other words: The pulse width is an direct function of the phase relationship
> of the clocks + an error function which is an direct function of the phase
> relationship between the clocks.

How often do you see this, 4 or 8 times per 2.5MHz cycle ?

> 
> It seems as if the phase state of one of the signals can have an linear like
> modulating effect on the phase state of the second signal (and perhaps vice
> versa). Some of you may come to the conclusion that +/-450 ps is not an
> number to cause real world troubles but in my case: The whole arrangement
> has the intention to measure phase fluctuations of the input clocks that ARE
> REALLY THERE but that are smaller at least one order of magnitude than the
> noticed errors. And that is why +/-450 ps is an real annoying number for me.
> 
> Any hint will be highly appreciated
> TIA, Ulrich Bangert

I think I have followed this.
If you are trying to 'zoom into' the phase to high precisons, using
analog Phase integration, there  are some rules to follow.

Vcc and Gnd must be VERY clean.
That means no other clocks, and /4 is going to cause more edges and
bounce, plus Vdd impedance noise is usually quite bad on CPLDs.
Any edge that is very close to another, WILL move the threshold, and
so cause phase non-linearities.
Normally, these are so small, well under Tpd, so in the digital domain
they do not matter much. [Some CPLDs will show Tpd delta, vs outputs loded ]

This stuff is NOT on the chip designer's radar :)

So, do not use a CPLD as the Phase Comparitor, but use an LVC Exor gate, 
preferable with Schmitt. eg LVC1G97, with analog Supply decoupling.

You may even find, you cannot have both non-locked frequencies in the
same package, so may need separate /4 blocks

Also XOR gates will be quite good at 90' output, but will not be linear
at needle pulse phase outputs, so if you need 360' phase with linearity,
I would suggest look at dual quadrature XOR phase comparisons.
(so one is in mid scale, when the other hits the edges)
( or even more phases, 4 would be simple from 10MHz, and use 4 ADC
channels - then 3 of the 4 would be low-error )

-jg


Article: 121210
Subject: Re: Xilinx FPGA to interface to special I/O
From: "Albert Nguyen" <>
Date: Thu, 28 Jun 2007 05:32:37 -0700
Links: << >>  << T >>  << A >>
John,

Thanks for you input. I looked at the ADUM1401 datasheet. So you are suggesting that on the FPGA side of this device, I connect the Vdd1 to 2.5 and Gnd1 to ground but on the other side of this device I connect the Vdd2 to +1.2 and GND2 to -1.3V. Is that correct?

Albert

Article: 121211
Subject: Re: Xilinx FPGA to interface to special I/O
From: "Albert Nguyen" <>
Date: Thu, 28 Jun 2007 05:36:57 -0700
Links: << >>  << T >>  << A >>
Ben,

I am not able to see your picture clearly. I think that simple bipolar npn transistor can work if the biasing is done right. I am bit concerned about the rise time if the biaising is not done right.

Thanks.

Albert

Article: 121212
Subject: Re: Xilinx FPGA to interface to special I/O
From: "Albert Nguyen" <>
Date: Thu, 28 Jun 2007 06:04:49 -0700
Links: << >>  << T >>  << A >>
John H,

The traget device will be running its VCC at 1.2V and Ground at -1.3V. Normally it will be running at 2.5 and 0 but in my application I need to run at +1.2V and -1.3V in order to comply with the differential electrical specification. But in doing so, the sideband control pins (SPI Bus pins) electrical changes.

You asked if I can get by without ground reference I/O. Are you suggesting to connect the FPGA outputs SCLK and SERIAL DATA IN, directly to the target device?

If it is just a matter of scope probing then I can get by without ground reference i/o.

Thanks.

Albert

Article: 121213
Subject: Re: Xilinx FPGA to interface to special I/O
From: John_H <newsgroup@johnhandwork.com>
Date: Thu, 28 Jun 2007 13:09:18 GMT
Links: << >>  << T >>  << A >>
Albert Nguyen wrote:
> John,
> 
> Thanks for you input. I looked at the ADUM1401 datasheet. So you are suggesting that on the FPGA side of this device, I connect the Vdd1 to 2.5 and Gnd1 to ground but on the other side of this device I connect the Vdd2 to +1.2 and GND2 to -1.3V. Is that correct?
> 
> Albert

Absolutely NOT my suggestion.

You want the FPGA to interface to those odd voltages.  Hook the FPGA 
Vcco to +1.2V and the FPGA GND signals all to -1.3V.  Just perform a 
mental shift of all FPGA voltaqes by 1.3V *IF* there are no other I/O 
that must interface as system ground referenced signals.  If you can 
make *all* I/O a 2.5V swing relative to -1.3V, everything can flow.

If you have TTL signals going in one side from an external source and 
the +1.2/-1.3V signalling on the other side, you will need external 
signal translation.  If your system is fully contained, there is no 
explicit need to make the ground reference for pushbutton-driven logic 
and the ground reference for the funky I/O levels of your unusual device 
the same potential.

All I'm suggesting is a mental shift of what "ground" is for an entire 
device.  But only if it can be applicable to the entire device.

Article: 121214
Subject: Re: Xilinx Modelsim XE-III 6.2g no more Systemverilog support?
From: "Xilinx User" <anonymous@net.com>
Date: Thu, 28 Jun 2007 06:11:37 -0700
Links: << >>  << T >>  << A >>
"HT-Lab" <hans64@ht-lab.com> wrote in message 
news:x_Jgi.5846$nE2.2947@newsfe3-win.ntli.net...
>> Anyway, Modelsim XE-III 6.2c starter-edition ran
>> Systemverilog simulations just fine.  So did Xilinx remove
>> this feature from XE-III 6.2g?  Nowhere in Xilinx's
>> online documentation, does Xilinx claim to support
>> Systemverilog.  But I'd like to get a definitive/official
>> answer.
> ...
> Do you have the sv_std folder in your installation directory? (I have it 
> on my PE installation).

I checked my \modelsim_xe_starter dir, and the sv_std subdir is there.
From what I can tell, the 6.2g installer puts the files there, but the
simulator refuses to load them if the simulation contains any
Systemverilog modules/submodules.

Mentor's free Modelsim PE Student Edition (6.3p1) runs Systemverilog
simulations just fine...though I hope there isn't some kind of weird
interaction when multiple Modelsims are installed on the same
PC! 



Article: 121215
Subject: Re: Analogue like signal interaction within cpld possible ????
From: "Ulrich Bangert" <df6jb@ulrich-bangert.de>
Date: Thu, 28 Jun 2007 15:18:53 +0200
Links: << >>  << T >>  << A >>
Jim,

thanks for your remarks! Because I did not want to make it too difficult I
simplified my explanation a bit and left out some things that I regarded not
significant for the problem: It is NOT the cpld's xor output directly that I
am trying to integrate, which would be really very difficult with the
intended precision.

Instead this output merely drives an precision high speed diode based switch
built from some HSMS-2812 which connects an summing rc-element alternating
with two reference voltages that are indeed of highest quality in terms of
precicion, tempco and 'clean-ness' and yes, low impedance. While this
analogue circuitry has been suspected to be the source of problems it has
now (where the direct comparison with the TIC based measurments was
possible) turned out to work like charming.

> So, do not use a CPLD as the Phase Comparitor, but use an LVC Exor gate,
> preferable with Schmitt. eg LVC1G97, with analog Supply decoupling.

Using an external xor will be the next thing that I am going to try.
However, even this external xor will only drive the switch described above
and therefore its supply will be less critical than you suggest. Because I
am out for speed (10 MHz may not be the highest frequencies to compare) I
ordered some 74AHC1G86 from Farnell. Do you think that the LVC part could be
the better performer due to the Schmitt trigger?

> You may even find, you cannot have both non-locked frequencies in the
> same package, so may need separate /4 blocks

This will be the next-next thing to do. Again I simplified a bit: The divide
by 4 flip-flops are the things that provide symmetrical quadrature outputs.
In front of them are programmable predividers that enable the circuit to
compare two signals of not the same frequency. However for the experiment
described these predividers were de-activated. These predividers are the
reason for using the 'big' 75108. With two separate packages I will be able
to use smaller cplds.

> Also XOR gates will be quite good at 90' output, but will not be linear
> at needle pulse phase outputs, so if you need 360' phase with linearity,
> I would suggest look at dual quadrature XOR phase comparisons.
> (so one is in mid scale, when the other hits the edges)

Basically that is the reason for dividing by 4 but I did not mention the
additional quadrature outputs. The circuit is indeed exactly as you suggest.
It has an small microcontroller that looks at the voltages of two quadrature
phase comparators with an LTC2402, chooses which is the more appropiate one
to use and automatically corrects for the 'jump' in phase when switching
between the quadrature outputs. All of this works even better than expected.
It is just that the cpld which has not been suspected at all as an possible
source of problems now turnes out to be the true beast.

> This stuff is NOT on the chip designer's radar :)

Surely not! Nor has it been on the radar of the designers of the MECL gates
that HP used to build their K34-5991A linear phase comparator from! But
sometimes using digital stuff for analogue purposes and vice versa can be
very funny and shows that the difference is sometimes not that strict.

> Any edge that is very close to another, WILL move the threshold, and
> so cause phase non-linearities.

Yes, from some earlier experiments I would have suspected & accepted THIS.
But the error function that I tried to describe covers the COMPLETE range of
phase-relationships that the two signals can have and that is what makes me
wonder. If you supply an address to where I can send something I will be
glad to send you an image of it.

Best regards
Ulrich Bangert

"Jim Granville" <no.spam@designtools.maps.co.nz> schrieb im Newsbeitrag
news:46839488$1@clear.net.nz...
> Ulrich Bangert wrote:
> > Gents,
> >
> > please allow me to confront you with some strange timing behaviour which
I
> > have measured with an Xilinx  XC95108 cpld.
> >
> > Consider two well conditioned clock signals of 10 MHz (both having
EXACTLY
> > the same frequency) entering the cpld. Inside the cpld each clock signal
is
> > divided by 4 by means of two d-flip-flops. The two resulting 2.5 Mhz
signals
> > enter an exclusive-or-gate which delivers an output signal where the
> > pulse/pause-relationship directly depends on the phase relationship of
the
> > two input clocks.
> >
> > If some of you feel reminded to something that you have seen before:
Yes,
> > basically this is the principle of an so called linear phase comparator
> > which has been used to compare high stability clocks (for example cesium
> > clocks) against each other before high resolution time interval counters
> > like the HP5370 or the Stanford Research SR620 were available.
> >
> > Now imagine one of the two clocks is de-tuned by exactly 0.001 Hz. It is
a
> > bit beyond the discussion HOW this is achieved but you may believe me
that
> > this is possible and that THIS is not part of the discussed problem. Now
the
> > phase relationship of the clocks changes slowly in time as does the
> > pulse/pause relationship behind the xor gate. The pulse/pause
relationship
> > of the xor's output can be measured by two completely different methods:
> >
> > a) by generating an dc voltage which is directly proportional to the
> > pulse/pause relationship (again a bit tricky if you want it to be an
really
> > high resolution measurement, but it  can  be done)
> >
> > b) by directly measuring the output pulse width with an high resolution
time
> > interval counter like the SR620 having a 25 ps single shot resolution
for
> > time interval measurements.
> >
> > It is important to note that both methods to measure can be applied at
the
> > same time and that both methods (although based on completely different
> > physical laws) deliver results that despite some statistical
fluctuations
> > are basically the same. That is why I am pretty sure that what I measure
is
> > really an property of the signal itself and not one of the measurement
> > apparatus.
> >
> > If I record the pulse width over time using the two methods and display
it
> > graphically it looks like an pretty linear relationship at the first
glance.
> > If however some math is applied to make it evident how good the linear
> > relationship really is met then the result is that there are
fluctuations in
> > the pulse width in the order of some +/-450 ps from the expected values.
> >
> > About these fluctuations the following facts are known:
> >
> > 1) They are not existent in the inputs clocks
> >
> > 2) Expressed in time units as well as expressed as an dc voltage the
> > fluctuations are orders of magnitude bigger than the resolution and
> > precision of the time/dc measurement.
> >
> > 3) The fluctuations are by no means of stochastical nature. Instead, If
an
> > positive fluctuation is noticed at an certain phase between the clock
> > signals, an fluctuation of the same magnitude and sign  will be noticed
the
> > next time when the clock signals have the same phase relationship. Or in
> > other words: The pulse width is an direct function of the phase
relationship
> > of the clocks + an error function which is an direct function of the
phase
> > relationship between the clocks.
>
> How often do you see this, 4 or 8 times per 2.5MHz cycle ?
>
> >
> > It seems as if the phase state of one of the signals can have an linear
like
> > modulating effect on the phase state of the second signal (and perhaps
vice
> > versa). Some of you may come to the conclusion that +/-450 ps is not an
> > number to cause real world troubles but in my case: The whole
arrangement
> > has the intention to measure phase fluctuations of the input clocks that
ARE
> > REALLY THERE but that are smaller at least one order of magnitude than
the
> > noticed errors. And that is why +/-450 ps is an real annoying number for
me.
> >
> > Any hint will be highly appreciated
> > TIA, Ulrich Bangert
>
> I think I have followed this.
> If you are trying to 'zoom into' the phase to high precisons, using
> analog Phase integration, there  are some rules to follow.
>
> Vcc and Gnd must be VERY clean.
> That means no other clocks, and /4 is going to cause more edges and
> bounce, plus Vdd impedance noise is usually quite bad on CPLDs.
> Any edge that is very close to another, WILL move the threshold, and
> so cause phase non-linearities.
> Normally, these are so small, well under Tpd, so in the digital domain
> they do not matter much. [Some CPLDs will show Tpd delta, vs outputs
loded ]
>
> This stuff is NOT on the chip designer's radar :)
>
> So, do not use a CPLD as the Phase Comparitor, but use an LVC Exor gate,
> preferable with Schmitt. eg LVC1G97, with analog Supply decoupling.
>
> You may even find, you cannot have both non-locked frequencies in the
> same package, so may need separate /4 blocks
>
> Also XOR gates will be quite good at 90' output, but will not be linear
> at needle pulse phase outputs, so if you need 360' phase with linearity,
> I would suggest look at dual quadrature XOR phase comparisons.
> (so one is in mid scale, when the other hits the edges)
> ( or even more phases, 4 would be simple from 10MHz, and use 4 ADC
> channels - then 3 of the 4 would be low-error )
>
> -jg
>



Article: 121216
Subject: How to write constraints with a clock enable?
From: Uwe Bonnes <bon@hertz.ikp.physik.tu-darmstadt.de>
Date: Thu, 28 Jun 2007 13:34:25 +0000 (UTC)
Links: << >>  << T >>  << A >>
Hello,

lets take this verilog example snipplet

reg clk_en;
reg [<WIDE>:0] wide_reg;

always @(posedge clk)
   begin
      clk_en <= !clk_en;
      wide_reg <= <some complicated action>;
   end

Now synthesis expectedly finds a delay for the wide_reg a little longer then
the projected clk. I think, I am right that with toggling clk_en, I can
effectively double the time the <some complicated action> path may take
without causing problems.

How do I constrain this path in the UCF file  so that ISE doesn't try to
optimize that path?

Thanks 

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

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

Article: 121217
Subject: Re: Xilinx FPGA to interface to special I/O
From: "Albert Nguyen" <>
Date: Thu, 28 Jun 2007 06:38:07 -0700
Links: << >>  << T >>  << A >>
Having FPGA VCC on 1.2V and GND on -1.3V is not possible as it affects many other FPGA signals.

Thanks.

Albert

Article: 121218
Subject: Re: Bit error counter - how to make it faster
From: Terje Mathisen <terje.mathisen@hda.hydro.com>
Date: Thu, 28 Jun 2007 15:40:59 +0200
Links: << >>  << T >>  << A >>
gamer wrote:
> My goal is to implement a bit-error counter targeting 1GHz. The
> datawidth is parametrizable. I started off this way,
> 
> Verilog code:
> ----------
> assign mismatch[datawidth-1:0]  =  input_data ^ expected_data;
> assign matched  =  ~( | mismatch);  // reduction NOR
> 
> always @(posedge clk  or  posedge reset) begin
>    if (reset)
>       error_count = 0;
>    else if (~matched)
>       for (i=0; i<datawidth; i=i+1)
>          error_count = error_count + mismatch[i];
> end
> ---------/////////----------------------
> The above meets timing for small datawidths (like 8-bits) and starts

Remember this, it is a key to a possible solution!

> failing to meet timing once the datawidth gets larger. I will be glad
> for suggestions of alternate ways to implement this bit-error counter.
> In practice our datawidths could go upto 256 bits.

You need to parallelize your error counter, particularly for very wide 
(256-bit?) paths:

A few layers of full adders to reduce the 256 input lines into a more 
reasonable number, then one or more carry-save accumulators to gather 
these into something that can be handled very quickly.

Only when reading out the number of errors do you propagate the carries 
to generate the final/real counts.

Terje

-- 
- <Terje.Mathisen@hda.hydro.com>
"almost all programming can be viewed as an exercise in caching"

From tbrown@tyzx.com Thu Jun 28 07:41:53 2007
Path: newsdbm02.news.prodigy.net!newsdst02.news.prodigy.net!prodigy.com!newscon02.news.prodigy.net!prodigy.net!nx01.iad01.newshosting.com!newshosting.com!130.81.64.211.MISMATCH!cycny01.gnilink.net!spamkiller2.gnilink.net!gnilink.net!trndny06.POSTED!95dec472!not-for-mail
From: Terry Brown <tbrown@tyzx.com>
Subject: Re: Xilinx Modelsim XE-III 6.2g no more Systemverilog support?
Newsgroups: comp.lang.verilog,comp.arch.fpga
References: <h1Dgi.4487$vi5.1602@newssvr17.news.prodigy.net>
User-Agent: Pan/0.125 (Potzrebie)
Message-Id: <pan.2007.06.28.14.40.37@tyzx.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Lines: 53
Date: Thu, 28 Jun 2007 14:41:53 GMT
NNTP-Posting-Host: 71.111.69.155
X-Complaints-To: abuse@verizon.net
X-Trace: trndny06 1183041713 71.111.69.155 (Thu, 28 Jun 2007 10:41:53 EDT)
NNTP-Posting-Date: Thu, 28 Jun 2007 10:41:53 EDT
Xref: prodigy.net comp.lang.verilog:36520 comp.arch.fpga:133081
X-Received-Date: Thu, 28 Jun 2007 10:41:54 EDT (newsdbm02.news.prodigy.net)

I think Mentor mistakenly thinks that further restricting their licenses 
will make customers purchase more expensive licenses because they can't 
live without Mentor products.  

With the upgrade from Modelsim Designer 6.1f to Modelsim 6.2f, you lose 
the ability to run Designer in PE mode--this without any notification, 
and without grandfathering in upgrades for existing paying customers at 
no charge.

A while ago, they similarly restricted USB based key licenses so that you 
couldn't run multiple copies on a single machine, even if you did have 
valid licenses and keys.

I'm going to switch to Riviera--Linux versions at reasonable pricing, 
nearly twice as fast as Modelsim PE, and hungry enough to actually think 
the customer might need real support.

Terry Brown

On Wed, 27 Jun 2007 17:11:55 -0700, Xilinx User wrote:

> I upgraded my Modelsim XE-III 6.2c starter edition to Modelsm XE-III
> 6.2g starter edition.  Before isntalling the new software, I uninstalled
> 6.2c (from Control Panel), and then I deleted the
> \modelsim_xe_starter directory on my hard-drive.
> 
> After the upgrade, I recycled the license.dat file from the old modelsim
> starter edition. (The license checker says it's valid.) I tried running
> some Systemverilog testbenches I had... all of them produce the same
> fatal error.  I can compile the code without problem. But when I try to
> start the simulation (using the 'vsim' command from the Modelsim
> command-line), I get the following error message:
> 
> \modelsiim_xe_starter\win32xeoem/../sv_std is not compiled with XE
> simulator.
> 
> My Systemverilog testbenches have a combination of Verilog-2001 and
> Systemverilog modules, but I tried a simple testcase with just a single
> Systemverilog module -- same problem.  This was just a simple .sv file
> with an interface declaration (but no 'advanced' features that require
> the Questa license.)  I also compiled a simple (single-file) VHDL
> testbench and (single-file) Verilog-2001 testbench.  Both compiled and
> simulated just fine.
> 
> i was going to suggest buying a few XE-III (full) licenses, but that was
> contingent upon, apparently, an undocumented/unofficial support for
> Systemverilog.  Now, I'll probably suggest getting (Mentor) Modelsim-PE.
> 
> Anyway, Modelsim XE-III 6.2c starter-edition ran Systemverilog
> simulations just fine.  So did Xilinx remove this feature from XE-III
> 6.2g?  Nowhere in Xilinx's online documentation, does Xilinx claim to
> support Systemverilog.  But I'd like to get a definitive/official
> answer.

Article: 121219
Subject: USB JTAG Programming
From: neilla@pipstechnology.co.uk
Date: Thu, 28 Jun 2007 07:49:41 -0700
Links: << >>  << T >>  << A >>
I'm looking at adding an embedded USB JTAG programmer onto our latest
board, and am just looking for a bit of advice.  The board has on it
an Spartan 3, and an XCF08P Platform Flash prom, the main processor on
the board is a Compulab computer on module.  We need to be able to
program the flash in system using the Compulab CoM.  We currently do
this using the LPC interface on the CoM, and an extra CPLD, using the
xilinx JDrive software.  Currently doing an erase, program, and verify
of the XCF08P takes ~60 seconds.  I was thinking it might be a nicer
solution to use a USB device like the FTDI 2232 to give us JTAG
access, but would like a bit of advice as to how easy it is to use
these things, and is the programming time likely to be any quicker.

Neill.


Article: 121220
Subject: Re: Bit error counter - how to make it faster
From: "comp.arch.fpga" <ksulimma@googlemail.com>
Date: Thu, 28 Jun 2007 15:12:24 -0000
Links: << >>  << T >>  << A >>
On 28 Jun., 15:40, Terje Mathisen <terje.mathi...@hda.hydro.com>
wrote:
> A few layers of full adders to reduce the 256 input lines into a more
> reasonable number, then one or more carry-save accumulators to gather
> these into something that can be handled very quickly.
>
> Only when reading out the number of errors do you propagate the carries
> to generate the final/real counts.

In Virtex-5 the 6-LUTs point to a 6-to-3 reduction instead of full
adders.
You can also use BRAMs for an 11 to 4 reduction.
512 bits at 500MHz might be easier than 256 bits at 1GHz.


Kolja Sulimma


Article: 121221
Subject: Re: How to write constraints with a clock enable?
From: Gabor <gabor@alacron.com>
Date: Thu, 28 Jun 2007 08:24:35 -0700
Links: << >>  << T >>  << A >>
On Jun 28, 9:34 am, Uwe Bonnes <b...@hertz.ikp.physik.tu-darmstadt.de>
wrote:
> Hello,
>
> lets take this verilog example snipplet
>
> reg clk_en;
> reg [<WIDE>:0] wide_reg;
>
> always @(posedge clk)
>    begin
>       clk_en <= !clk_en;
>       wide_reg <= <some complicated action>;
>    end
>
> Now synthesis expectedly finds a delay for the wide_reg a little longer then
> the projected clk. I think, I am right that with toggling clk_en, I can
> effectively double the time the <some complicated action> path may take
> without causing problems.
>
> How do I constrain this path in the UCF file  so that ISE doesn't try to
> optimize that path?
>
> Thanks
>
> --
> Uwe Bonnes                b...@elektron.ikp.physik.tu-darmstadt.de
>
> Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
> --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------


I'm assuming you mean:
 always @(posedge clk)
    begin
       clk_en <= !clk_en;
       if (clk_en) wide_reg <= <some complicated action>;
    end

You can define groups of flip-flops whose clock enable is clk_en
like:

NET "clk_en" TNM_NET=FFS(*) CKEN_FFGRP;

Then use FROM .. TO timing constraints or TIG constraints on the
grouped elements.

TIMESPEC "TS_CKEN"=FROM "CKEN_FFGRP" TO "CKEN_FFGRP" TS_CLKPERIOD*2;

These examples are based on the 6.1i constraints guide, so if you
are using a newer version you should refer to the latest constraints
guide.

HTH,
Gabor


Article: 121222
Subject: Re: Xilinx FPGA to interface to special I/O
From: "John_H" <newsgroup@johnhandwork.com>
Date: Thu, 28 Jun 2007 08:47:22 -0700
Links: << >>  << T >>  << A >>
<Albert Nguyen> wrote in message news:eea7b1c.7@webx.sUN8CHnE...
> Having FPGA VCC on 1.2V and GND on -1.3V is not possible as it affects 
> many other FPGA signals.
>
> Thanks.
>
> Albert

Then you absolutely need level translators.

I feel I lost you on the idea of shifting your rails to a different absolute 
voltage while keeping all the rails and signals properly specified relative 
to each other.  It may be your system doesn't need the absolute voltages 
you're planning.  Since I don't know enough about your system to see if a 
compromise can be made, just design level translators.

You might look at using PNP transistors with a pull-down to -1.3V to provide 
the +1.2V to -1.3V swing. 



Article: 121223
Subject: Re: USB JTAG Programming
From: Teo <vit.matteo@gmail.com>
Date: Thu, 28 Jun 2007 15:57:46 -0000
Links: << >>  << T >>  << A >>
On 28 Giu, 16:49, nei...@pipstechnology.co.uk wrote:
> I'm looking at adding an embedded USB JTAG programmer onto our latest
> board, and am just looking for a bit of advice.  The board has on it
> an Spartan 3, and an XCF08P Platform Flash prom, the main processor on
> the board is a Compulab computer on module.  We need to be able to
> program the flash in system using the Compulab CoM.  We currently do
> this using the LPC interface on the CoM, and an extra CPLD, using the
> xilinx JDrive software.  Currently doing an erase, program, and verify
> of the XCF08P takes ~60 seconds.  I was thinking it might be a nicer
> solution to use a USB device like the FTDI 2232 to give us JTAG
> access, but would like a bit of advice as to how easy it is to use
> these things, and is the programming time likely to be any quicker.
>
> Neill.

Hi,
I added support for the FTDI2232 chip to Jamplayer (from Altera). With
this tool you can program both Altera and Xilinx device.
The input file is in STAPL format, you can generate it with ISE.
I tested the FTDI2232 version with Altera device (Stratix and EPC
configuration device). I tested another porting of Jamplayer (using
GPIOs from an ARM9) with XC9500 series. I can send you the FTDI2232
version.
I don't know the programming time with XCF08P.

Matteo


Article: 121224
Subject: Re: How to create simple design?
From: evansamuel@charter.net
Date: Thu, 28 Jun 2007 18:00:43 GMT
Links: << >>  << T >>  << A >>
The 'b1', 'b2', etc. on the gates are the number of inverted inputs.
Got to the help topics for software help, or software manuals
 (libraries guide) for information on the available gates.

Expand 'Generate Program FIle' and double click 'Configure Device'
The Program iMPACT will start.  It will sometimes
attempt to find the programming cable and identify the
devices in the JTAG chain.  If the cable or board
is not connected it will generate and error.

iMPACT is used to download all Xilinx devices using JTAG.
You can download supported proms, cpld, and fpga devices.
Go to 'Help/Help Topics' to learn about iMPACT.

Schematic was originally the only way to design with Xilinx
tool upto version 4.2.  Then VHDL/VERILOG became available
for developing large designs.  Schematic design, using gate
primitive is useful only for small designs.  It is still available
mostly for top level block design and viewing schematics of synthesized
VHDL/VERILOG code.



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