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 146700

Article: 146700
Subject: Re: Newbie Coding Question
From: David Wiltshire <dw_56@hotmail.com>
Date: Fri, 26 Mar 2010 04:09:43 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 26, 8:43=A0pm, Alan Fitch <alan.fi...@spamtrap.com> wrote:

>     there are two (or two and a half?) answers
>
> 1. You do it manually.
> 2. You pay a lot of money for a behavioural synthesis tool
> 2.5 Certain RTL synthesis tools do sometimes understand a so-called
> implicit state machine style,

Thanks Alan.  That makes it completely clear.  It's an epiphanhy
moment in hardware design for me. I get how the flow of information
through the hardware works.  And how difficult this is!  It's all just
lots of work to manual labour!

Dave

Article: 146701
Subject: Re: baud rates etc
From: David Brown <david@westcontrol.removethisbit.com>
Date: Fri, 26 Mar 2010 12:19:28 +0100
Links: << >>  << T >>  << A >>
On 26/03/2010 10:34, da_wils@hotmail.com wrote:
> Hi,
>
> I'm making a uart that will run at the standard baud rates and have a
> bit of a query,
> My board has a 50Mhz clk so I've used this to create a 1.8432Mhz clock
> then derive all the baud clocks from it,,eg,
> -- 50mhz/ 1843200 = 27.1267
> -- 13 bit acc = 4096 msb
> -- divided by 151
> -- 4096/151 =  27.1258 -- close enough
> -- gives 1.843262MHz clock
>
> this is fine for TX but when it comes to RX where the accepted sample
> clk is 16x the baud rate I hit a few problems. I wanted to sample the
> incoming bit period at 4 16x clocks, 8 16x clocks and 12 16x clock and

Sample at clocks 7, 8 and 9 and take a majority vote.  That's how 
(almost) all standard uarts handle receive sampling.  Spreading it out 
by using clock 4, 8 and 12 gives you no better noise immunity and makes 
your uart far more sensitive to baud rate accuracy.

Start bit edges need to be sampled at every 16x clock, of course.

> use the theory that if two samples match then RX bit is good, It's
> this generation of a 16x clock that is causing me problems, not easy
> to create for all baud rates. At the moment I'm sampling the RX at
> 50MHz and taking samples at three points, this scheme works but seems
> a bit inefficient due to having to have a bank of constants with the
> the various count values for different baud rates.
>
> Has anyone come across this problem ?

All standard baud rates are integer fractions of 115200.  So when you 
have your 1.84 MHz clock, you simply divide it by the baud divisor to 
get your 16x clock (i.e., divide by 1 for 16 x 115200, by 6 for 16 x 
19200, etc.).

If it's easier for your hardware, use a faster clock that 1.84 MHz as 
the base - you can get away with 1% error (theoretically up to 5% total) 
in the baud clock.

Article: 146702
Subject: Re: result on hyperterminal is not displayed
From: David Brown <david@westcontrol.removethisbit.com>
Date: Fri, 26 Mar 2010 12:22:08 +0100
Links: << >>  << T >>  << A >>
On 26/03/2010 10:38, weldat wrote:
> Hi every body;
> i am working on xilinx EDK with MicroBlaze soft core processor. i am using
> Virtex 5 ML506 platform studio and my EDK is EDK 9.2
> on this processor i am downloading C code for Elliptic curve diffie-hellman
> key exchange and it is done but result is not displayed on the
> hyperterminal so is there any body who can help me how to fix my problem?
> but the connetion of the RS232_uart is working properly i have checked it
> with simple C code. the baud rate is all ok
> thank you in advance.
> kind regards
> weldat	

I have no idea about your system, but hyperterminal is notoriously 
unreliable and entirely unsuitable to embedded development.  Try a 
decent terminal emulator first to eliminate that source of problem. 
Many people (including me) like Tera Term Pro, but there are hundreds of 
alternatives.


Article: 146703
Subject: Re: USB 3.0 implementation on FPGA
From: wojtek <wojtekpowiertowski@gmail.com>
Date: Fri, 26 Mar 2010 04:30:55 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 26, 11:18=A0am, "Maurice Branson" <trauben...@arcor.de> wrote:
> "Andrew Jackson" <a...@nospam.com> wrotenews:X_adnaUfiO556jHWnZ2dnUVZ8l2d=
nZ2d@eclipse.net.uk...
>
> > ways, you would be better doing a USB2.0 device and sticking on a suita=
ble
> > USB PHY for the physical interface. =A0There aren't many USB 3.0 hosts
> > around yet against which you could test your device either: lots
>
> Thanks, Andrew!
>
> Sounds resonable to me. So if I start with 2.0 is there a compatibility t=
hat
> I may "expand" my design to a 3.0 core or is it totally different? I lear=
ned
> from what I've read here and in the www that I need at least a separate P=
HY
> because that is something that I cannot to in the FPGA fabric. Are there =
any
> USB 3.0 PHYs already available? Found nothing. :-(
>
> KR Maurica

3.0 core is basically separate from 2.0 on almost every layer, if you
have a usb 3.0 device it tries to connect using super speed and if
that is not available on the other side, the 3.0 core shuts down and
2.0/1.1 core starts its operation. The PHY is not publicly available,
because there is no market for it, right now only big companies
working on usb 3.0 appliances (like WD, Samsung, Intel, ...) have it
available.

Article: 146704
Subject: Wrong DDR communication
From: "Pierpaolo" <pierpaolo.passarelli@n_o_s_p_a_m.gmail.com>
Date: Fri, 26 Mar 2010 06:43:11 -0500
Links: << >>  << T >>  << A >>
Hi everyone,

I'm implenting a design on a Virtex4 that has to follow the communication
of a processor  with the ddr memory that is on the board. The board that
I'm using is an Avnet ADS-XLX-V4LX-DEV160. The bridge that link the
processor with the memory  at the end has a Xilinx component IOBUF to
transmit and receive data and strobe (bidirectional). 
It looks that all the signal sent to the memory are right, but the problem
is that the data signals received from the memory are always to 1 like if
the memory is turned off. I checked the file .ucf for the connection and it
looks right. 
Does someone know what could be the problem?

Thanks

Pierpaolo

	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 146705
Subject: Re: USB 3.0 implementation on FPGA
From: Antti <antti.lukats@googlemail.com>
Date: Fri, 26 Mar 2010 05:58:11 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 26, 1:30=A0pm, wojtek <wojtekpowiertow...@gmail.com> wrote:
> On Mar 26, 11:18=A0am, "Maurice Branson" <trauben...@arcor.de> wrote:
>
> > "Andrew Jackson" <a...@nospam.com> wrotenews:X_adnaUfiO556jHWnZ2dnUVZ8l=
2dnZ2d@eclipse.net.uk...
>
> > > ways, you would be better doing a USB2.0 device and sticking on a sui=
table
> > > USB PHY for the physical interface. =A0There aren't many USB 3.0 host=
s
> > > around yet against which you could test your device either: lots
>
> > Thanks, Andrew!
>
> > Sounds resonable to me. So if I start with 2.0 is there a compatibility=
 that
> > I may "expand" my design to a 3.0 core or is it totally different? I le=
arned
> > from what I've read here and in the www that I need at least a separate=
 PHY
> > because that is something that I cannot to in the FPGA fabric. Are ther=
e any
> > USB 3.0 PHYs already available? Found nothing. :-(
>
> > KR Maurica
>
> 3.0 core is basically separate from 2.0 on almost every layer, if you
> have a usb 3.0 device it tries to connect using super speed and if
> that is not available on the other side, the 3.0 core shuts down and
> 2.0/1.1 core starts its operation. The PHY is not publicly available,
> because there is no market for it, right now only big companies
> working on usb 3.0 appliances (like WD, Samsung, Intel, ...) have it
> available.

well, USB 3.0 is the first one that needs NO PHY

as the MGT's in some newer FPGA's are USB 3.0 capable directly
just wire MGT to usb 3.0 superspeed pins, and that about it

Antti


Article: 146706
Subject: Re: baud rates etc
From: John_H <newsgroup@johnhandwork.com>
Date: Fri, 26 Mar 2010 06:20:27 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 26, 5:34=A0am, da_w...@hotmail.com wrote:
> Hi,
>
> I'm making a uart that will run at the standard baud rates and have a
> bit of a query,
> My board has a 50Mhz clk so I've used this to create a 1.8432Mhz clock
> then derive all the baud clocks from it,,eg,
> -- 50mhz/ 1843200 =3D 27.1267
> -- 13 bit acc =3D 4096 msb
> -- divided by 151
> -- 4096/151 =3D =A027.1258 -- close enough
> -- gives 1.843262MHz clock
>
> this is fine for TX but when it comes to RX where the accepted sample
> clk is 16x the baud rate I hit a few problems. I wanted to sample the
> incoming bit period at 4 16x clocks, 8 16x clocks and 12 16x clock and
> use the theory that if two samples match then RX bit is good, It's
> this generation of a 16x clock that is causing me problems, not easy
> to create for all baud rates. At the moment I'm sampling the RX at
> 50MHz and taking samples at three points, this scheme works but seems
> a bit inefficient due to having to have a bank of constants with the
> the various count values for different baud rates.
>
> Has anyone come across this problem ?

Why not just run everything from the 50MHz clock directly?  Using
simple counters you can get as precise as you need for the UART
application whether for your 16x clock at high baud rates or 1x at the
lowest.  You could even go for more precision at the cost of 20ns of
clock jitter by using an accumulator as the divider rather than a
counter.

Article: 146707
Subject: Re: result on hyperterminal is not displayed
From: John_H <newsgroup@johnhandwork.com>
Date: Fri, 26 Mar 2010 06:27:19 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 26, 5:38=A0am, "weldat"
<gwelekiros@n_o_s_p_a_m.n_o_s_p_a_m.gmail.com> wrote:
> Hi every body;
> i am working on xilinx EDK with MicroBlaze soft core processor. i am usin=
g
> Virtex 5 ML506 platform studio and my EDK is EDK 9.2
> on this processor i am downloading C code for Elliptic curve diffie-hellm=
an
> key exchange and it is done but result is not displayed on the
> hyperterminal so is there any body who can help me how to fix my problem?
> but the connetion of the RS232_uart is working properly i have checked it
> with simple C code. the baud rate is all ok
> thank you in advance.
> kind regards
> weldat =A0 =A0
>
> --------------------------------------- =A0 =A0 =A0 =A0
> Posted throughhttp://www.FPGARelated.com

I saw a thread recently where hyperterminal was dropping data.  It
turned out hyperterminal wasn't treating the hex '00 values as data
despite the attempts to make the transfer "binary" and gummed up the
whole effort.

If you're using raw data, perhaps you should change to where you
transfer ASCII hex characters instead.  In pseudocode: 4'h0 =3D=3D 8'c"0",
4'hf =3D=3D 8'c"F"

Article: 146708
Subject: Re: USB 3.0 implementation on FPGA
From: wojtek <wojtekpowiertowski@gmail.com>
Date: Fri, 26 Mar 2010 06:32:29 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 26, 1:58=A0pm, Antti <antti.luk...@googlemail.com> wrote:
> well, USB 3.0 is the first one that needs NO PHY
>
> as the MGT's in some newer FPGA's are USB 3.0 capable directly
> just wire MGT to usb 3.0 superspeed pins, and that about it
>
> Antti

That is the first time i hear abou MGT being compatible with USB 3.0
PHY, but I haven't doing anything in USB 3.0 topic for almost a year.
I must say I find it hard to believe thought, because USB 3.0 besides
translating digital signal to differential analog signal also
transmits USB 3.0 specific LFPS (low frequency pulse signaling) and
from what I learned the USB 3.0 PHY was supposed to take care of that
(just like latest PCI express PHY, which has similar LFPS technology).
I believe the MGT doesn't support that. But as I've said I hadn't even
researched it for some time, so I might be wrong.

Article: 146709
Subject: Re: baud rates etc
From: dave <da_wils@hotmail.com>
Date: Fri, 26 Mar 2010 07:03:19 -0700 (PDT)
Links: << >>  << T >>  << A >>
Thanks for all your answers,
I'll generate a16x clock and give it a try otherwise I don't see any
problem oversampling using the 50MHz clock
my 1.84Mhz clock uses the accumulator method with a 20ns jitter, seems
to run ok,

Dave

Article: 146710
Subject: Re: Ring Oscillator -> counter differences
From: Thomas Stanka <usenet_nospam_valid@stanka-web.de>
Date: Fri, 26 Mar 2010 08:15:14 -0700 (PDT)
Links: << >>  << T >>  << A >>
On 25 Mrz., 17:18, Jason Thibodeau <jason.p.thibod...@gmail.com>
wrote:
> Thinking about it further, I suppose I didn't mean stay exactly the
> same. I did expect differences, and I guess I confirm with you all that
> what I am seeing is normal. I have typically less than 5% fluctuations
> between runs.
>
> Thanks for all your input. It gives me a bit to think about.

The problem is, that your frequency might be very fast with 5 stage
ring oscillator. Expect the clock frequency to equal the gate delay of
not more than 5 gates :). Your counter will experience very fast clock
cycles which lead to results with no meaning if your counter is not
designed to work with that fast clock frequency.
Second problem, how do you avoid having more than one level
transaction in the oscillation ring?
(e.g. 01010).

bye Thomas



Article: 146711
Subject: Re: Xilinx Spartan6 Virtex6 Rollout
From: Aaron <aholtzma@gmail.com>
Date: Fri, 26 Mar 2010 08:42:23 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 25, 5:26=A0pm, "Brad Smallridge" <bradsmallri...@dslextreme.com>
wrote:
> > In North America, that is Avnet (as you have noted). =A0I suggest you
> > call them on the phone and request quotes and delivery.
>
> Why shouldn't Xilinx tell us when parts are available.
> They are the mfg. They probably have a better idea.
> Even an approximation would be better than nothing.

With Xilinx, I just look at the list of parts that have errata so far.
This will give you a good idea of what parts will go into production
first.

ah

Article: 146712
Subject: Re: XST optimization
From: Jason Thibodeau <jason.p.thibodeau@gmail.com>
Date: Fri, 26 Mar 2010 12:00:31 -0400
Links: << >>  << T >>  << A >>
On 03/25/2010 11:24 PM, David Wiltshire wrote:
> On Mar 26, 6:06 am, Jason Thibodeau<jason.p.thibod...@gmail.com>
> wrote:
>> Is it possible to get a detailed report out of XST, listing the gates it
>> has optimized out of a design? XST is removing some gates that I
>> specifically put into a design, and I want to prevent this. I can use
>> the XST constraints file, but I'd like to see exactly what it is doing.
>>
>> Googling hasn't turned up much, yet.
>>
>> Thanks
>> --
>> Jason Thibodeau
>
> Not that I'm experienced but whenever I've seen a similar question
> (missing logic) it's been optomised out because you haven't connected
> the output to anything.  Try connecting it to a pin out (even if
> that's not where you want it eventually) and see if it turns up.
>
> Dave

Yes, I ran across that and I connected the output. Only the last gate in 
the design is being synthesized. All the other gates, which connect to 
it, are being optimized out.

-- 
Jason Thibodeau

Article: 146713
Subject: Re: Ring Oscillator -> counter differences
From: Jason Thibodeau <jason.p.thibodeau@gmail.com>
Date: Fri, 26 Mar 2010 12:04:56 -0400
Links: << >>  << T >>  << A >>
On 03/26/2010 11:15 AM, Thomas Stanka wrote:
> On 25 Mrz., 17:18, Jason Thibodeau<jason.p.thibod...@gmail.com>
> wrote:
>> Thinking about it further, I suppose I didn't mean stay exactly the
>> same. I did expect differences, and I guess I confirm with you all that
>> what I am seeing is normal. I have typically less than 5% fluctuations
>> between runs.
>>
>> Thanks for all your input. It gives me a bit to think about.
>
> The problem is, that your frequency might be very fast with 5 stage
> ring oscillator. Expect the clock frequency to equal the gate delay of
> not more than 5 gates :). Your counter will experience very fast clock
> cycles which lead to results with no meaning if your counter is not
> designed to work with that fast clock frequency.
> Second problem, how do you avoid having more than one level
> transaction in the oscillation ring?
> (e.g. 01010).
>
> bye Thomas
>
>

Yes, I was discussing that with a colleague yesterday. The oscillator 
may be too fast for the counter to read it accurately. I'm using a the 
output oscillator signal to clock the counter, however the oscillation 
frequency may be too fast to meet the required set-up and hold time for 
the counter. I'm investigating that now.

-- 
Jason Thibodeau

Article: 146714
Subject: Re: result on hyperterminal is not displayed
From: nico@puntnl.niks (Nico Coesel)
Date: Fri, 26 Mar 2010 16:41:58 GMT
Links: << >>  << T >>  << A >>
"weldat" <gwelekiros@n_o_s_p_a_m.n_o_s_p_a_m.gmail.com> wrote:

>Hi every body;
>i am working on xilinx EDK with MicroBlaze soft core processor. i am using
>Virtex 5 ML506 platform studio and my EDK is EDK 9.2
>on this processor i am downloading C code for Elliptic curve diffie-hellman
>key exchange and it is done but result is not displayed on the
>hyperterminal so is there any body who can help me how to fix my problem?
>but the connetion of the RS232_uart is working properly i have checked it
>with simple C code. the baud rate is all ok
>thank you in advance.

Short pins 2 & 3 on the plug to see if characters get echoed when
typing.

-- 
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
nico@nctdevpuntnl (punt=.)
--------------------------------------------------------------

Article: 146715
Subject: Re: Ring Oscillator -> counter differences
From: Antti <antti.lukats@googlemail.com>
Date: Fri, 26 Mar 2010 11:12:54 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 26, 6:04=A0pm, Jason Thibodeau <jason.p.thibod...@gmail.com>
wrote:
> On 03/26/2010 11:15 AM, Thomas Stanka wrote:
>
>
>
>
>
> > On 25 Mrz., 17:18, Jason Thibodeau<jason.p.thibod...@gmail.com>
> > wrote:
> >> Thinking about it further, I suppose I didn't mean stay exactly the
> >> same. I did expect differences, and I guess I confirm with you all tha=
t
> >> what I am seeing is normal. I have typically less than 5% fluctuations
> >> between runs.
>
> >> Thanks for all your input. It gives me a bit to think about.
>
> > The problem is, that your frequency might be very fast with 5 stage
> > ring oscillator. Expect the clock frequency to equal the gate delay of
> > not more than 5 gates :). Your counter will experience very fast clock
> > cycles which lead to results with no meaning if your counter is not
> > designed to work with that fast clock frequency.
> > Second problem, how do you avoid having more than one level
> > transaction in the oscillation ring?
> > (e.g. 01010).
>
> > bye Thomas
>
> Yes, I was discussing that with a colleague yesterday. The oscillator
> may be too fast for the counter to read it accurately. I'm using a the
> output oscillator signal to clock the counter, however the oscillation
> frequency may be too fast to meet the required set-up and hold time for
> the counter. I'm investigating that now.
>
> --
> Jason Thibodeau

it depend the architecture and routing
its a good idea to run the ring oscillator to single flip flop that
divides by 2
the output of that FF is more likely in the range that is ok to use
in the same FPGA as "system clock"

the plain ring oscillator may run too fast

Antti




Article: 146716
Subject: Re: Ring Oscillator -> counter differences
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Fri, 26 Mar 2010 19:26:29 +0000 (UTC)
Links: << >>  << T >>  << A >>
Jason Thibodeau <jason.p.thibodeau@gmail.com> wrote:
> On 03/26/2010 11:15 AM, Thomas Stanka wrote:
(snip)

>> The problem is, that your frequency might be very fast with 5 stage
>> ring oscillator. Expect the clock frequency to equal the gate delay of
>> not more than 5 gates :). Your counter will experience very fast clock
>> cycles which lead to results with no meaning if your counter is not
>> designed to work with that fast clock frequency.

With routing delay being one of the slower parts of newer FPGAs
that doesn't seem so likely, unless...

>> Second problem, how do you avoid having more than one level
>> transaction in the oscillation ring?
>> (e.g. 01010).

That would speed up the count.  If you can route to an output
pin without changing the oscillator too much, then look at it
on a scope.
 
> Yes, I was discussing that with a colleague yesterday. The oscillator 
> may be too fast for the counter to read it accurately. I'm using a the 
> output oscillator signal to clock the counter, however the oscillation 
> frequency may be too fast to meet the required set-up and hold time for 
> the counter. I'm investigating that now.

It would be best to use the built-in clock distribution.

Otherwise, a ripple counter (from the 7493 days) should avoid
clock skew problems.  Another idea is to use a gray code counter.
I can see cases where clock skew on a very fast clock would give
strange results, but the OP never actually posted any counts.

To use a ripple counter, one would have to gate the clock, and
stop it long enough to read out the result.  If you use one
input to all five LUTs as a gate, that might make it more
likely to start in the desired state.  (And also might avoid
the optimizer removing inverters from the loops.)

-- glen

Article: 146717
Subject: Re: Ring Oscillator -> counter differences
From: Chris Maryan <kmaryan@gmail.com>
Date: Fri, 26 Mar 2010 12:28:16 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 26, 12:04=A0pm, Jason Thibodeau <jason.p.thibod...@gmail.com>
wrote:
> On 03/26/2010 11:15 AM, Thomas Stanka wrote:
>
>
>
>
>
> > On 25 Mrz., 17:18, Jason Thibodeau<jason.p.thibod...@gmail.com>
> > wrote:
> >> Thinking about it further, I suppose I didn't mean stay exactly the
> >> same. I did expect differences, and I guess I confirm with you all tha=
t
> >> what I am seeing is normal. I have typically less than 5% fluctuations
> >> between runs.
>
> >> Thanks for all your input. It gives me a bit to think about.
>
> > The problem is, that your frequency might be very fast with 5 stage
> > ring oscillator. Expect the clock frequency to equal the gate delay of
> > not more than 5 gates :). Your counter will experience very fast clock
> > cycles which lead to results with no meaning if your counter is not
> > designed to work with that fast clock frequency.
> > Second problem, how do you avoid having more than one level
> > transaction in the oscillation ring?
> > (e.g. 01010).
>
> > bye Thomas
>
> Yes, I was discussing that with a colleague yesterday. The oscillator
> may be too fast for the counter to read it accurately. I'm using a the
> output oscillator signal to clock the counter, however the oscillation
> frequency may be too fast to meet the required set-up and hold time for
> the counter. I'm investigating that now.
>
> --
> Jason Thibodeau- Hide quoted text -
>
> - Show quoted text -

The rule of thumb (at least for brand X FPGAs) is 500ps of propagation
delay per LUT. Assuming your ring buffer is actually getting generated
as you expect (and synthesis isn't reducing it to a single LUT not
gate), not including routing, I'd guess you're looking at ~400MHz as
an upper bound. Depending on your FPGA, this may or may not be
acceptable fundamentally in the fabric. Moreover, your counter has to
run at least this fast.

Chris

Article: 146718
Subject: Re: Newbie Coding Question
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Fri, 26 Mar 2010 19:31:19 +0000 (UTC)
Links: << >>  << T >>  << A >>
David Wiltshire <dw_56@hotmail.com> wrote:
(snip)
 
> Thanks Alan.  That makes it completely clear.  It's an epiphanhy
> moment in hardware design for me. I get how the flow of information
> through the hardware works.  And how difficult this is!  It's all just
> lots of work to manual labour!

I don't know that it is so much more difficult, but the thought
processes are different.  Some of use grew up in the days when
TTL gates were popular and easy to buy and play around with.

When digital clock that you bought in stores were mechanical, 
but you could build them from TTL (and maybe some MOS).
When freshman lab courses had students build projects out
of TTL gates.  As I understand it, now freshman labs only
do simulations, but never actually build anything!

-- glen

Article: 146719
Subject: Re: baud rates etc
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Fri, 26 Mar 2010 19:39:19 +0000 (UTC)
Links: << >>  << T >>  << A >>
dave <da_wils@hotmail.com> wrote:

> Thanks for all your answers,
> I'll generate a16x clock and give it a try otherwise I don't see any
> problem oversampling using the 50MHz clock
> my 1.84Mhz clock uses the accumulator method with a 20ns jitter, seems
> to run ok,

I used to have an Epson MX-100 printer connected to a TRS-80
color computer through a serial interface.  The serial interface
option is based on the intel 8049, such that the UART is done
in software.  (I once thought about dumping the ROM, but never did.)

The Color Computer also uses a software UART, directly timed
by loops in 6809 code.  One program I had didn't work so well,
and I found out that the printer likes faster clocks, but for
even slightly slower, it would fail.  A small change to the
timing loop in the 6809 code resolved the problems.

A 1% timing error accumulates over 10 bits as 10% of the
clock period.  With the 6% due to the 16x clock, and the
possible non 50% duty cycle input, you don't want to be
too far off, but a few percent isn't so bad.  (Leave some
margin for the other end, too.)

-- glen 

Article: 146720
Subject: Re: PROM for Spartan 6 FPGA
From: Jon Elson <jmelson@wustl.edu>
Date: Fri, 26 Mar 2010 14:44:31 -0500
Links: << >>  << T >>  << A >>
Aditi wrote:
> Hi,
> 
> I am planning to use a Spartan 6 FPGA (XC6SLX9) in my new design.
> Could someone suggest a reprogrammable PROM to configure this device,
> like the capacity of the Flash PROM needed ?
Also, SST has a line of flash proms.  I use their 1-mbit version on a 
smaller FPGA, but they have a 4 mb part, 
http://mouser.com/ProductDetail/Atmel/AT29LV040A-15TU/?qs=sGAEpiMZZMtI%252bQ06EiAoG1KfhKGNTAIqdwDuLxOe7u0%3d

I use the so-8 package, but they have a smaller chip-scale version.

Jon

Article: 146721
Subject: Re: PROM for Spartan 6 FPGA
From: Jon Elson <jmelson@wustl.edu>
Date: Fri, 26 Mar 2010 14:52:13 -0500
Links: << >>  << T >>  << A >>
Aditi wrote:
> Hi,
> 
> I am planning to use a Spartan 6 FPGA (XC6SLX9) in my new design.
> Could someone suggest a reprogrammable PROM to configure this device,
> like the capacity of the Flash PROM needed ?
OOPS, wrong part.  The part I'm using is the SST 25VF010A, the 4 Mbit 
part is the SST25VF040, they have a couple variants and package choices.
These things are MUCH cheaper than some other makers, and have worked 
quite well in my application.  I did have to write my own serial 
programming routine for them, but it wasn't too hard.

Jon

Article: 146722
Subject: Re: Any advice on which is the best book on CMOS digital circuit
From: Thomas Entner <thomas.entner@entner-electronics.com>
Date: Fri, 26 Mar 2010 13:19:42 -0700 (PDT)
Links: << >>  << T >>  << A >>
> The second one is basically useless.
> The reason is the estimate of a logic speed and how they are generated
> in most efficient way
> are the topics of HDL compilers and it becomes other people's
> business, not a digital logic designer's business.

Hi Weng,

I do not know the book, but it is hard for me to not disagree with the
statement, that a digital logic designer is not responsible for the
speed of the circuit. Especially when you are talking about domino
logic, etc. in your other posts, when I remember right ;-)

Regards,

Thomas

Article: 146723
Subject: Re: EMC discussion
From: Jonathan Bromley <jonathan.bromley@MYCOMPANY.com>
Date: Fri, 26 Mar 2010 20:45:36 +0000
Links: << >>  << T >>  << A >>
On Thu, 25 Mar 2010 18:41:06 +0000 (UTC), glen herrmannsfeldt wrote:

>> Why do we need power planes?  Are we trying to keep the "reference
>> rails" common between chips to a very high degree like we do with our
>> ground planes?
>
>Some drivers can pull up almost as much as down.  

True, for sure.  But in the olden days (and remember, I'm an
olden-days person) ground, but never power, was used as a
reference for inputs.  Is that still true?  My gut tells me
that CMOS inputs need both power and ground to be well-
behaved if they are to act sensibly.  Does anyone know
different?
-- 
Jonathan Bromley

Article: 146724
Subject: Re: Ring Oscillator -> counter differences
From: John_H <newsgroup@johnhandwork.com>
Date: Fri, 26 Mar 2010 13:54:54 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 26, 3:26=A0pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
>
> >> Second problem, how do you avoid having more than one level
> >> transaction in the oscillation ring?
> >> (e.g. 01010).
>
> That would speed up the count. =A0If you can route to an output
> pin without changing the oscillator too much, then look at it
> on a scope.

There's a strong possibility the I/O won't have the bandwidth to pass
the full signal.  A short back and forth for a small pulse might get
lost in the I/O.



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