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 143725

Article: 143725
Subject: Re: CPLD/FPGA with Linux
From: austin <austin@xilinx.com>
Date: Thu, 22 Oct 2009 10:42:15 -0700 (PDT)
Links: << >>  << T >>  << A >>
A very good source for students is:

http://www.digilentinc.com/

If you choose Xilinx Webpack for Linux (free download), and then you
can buy the small Spartan 3E board:

http://www.xilinx.com/tools/webpack.htm
(download webpack)

and

http://www.digilentinc.com/Products/Detail.cfm?NavPath=2,719,721&Prod=BASYS2
(3E pcb)

which is commonly used at many universities and schools (so there is a
lot of stuff on the web sites of universities and schools).

Programming tools (the JTAG programming cable) used with Linux are
always a bit tough to get to work (just read the posts on the subject)
as support of USB isn't as trivial as it is with 'Windoze.'

Austin

Article: 143726
Subject: Re: problem while receiving negative integer in microblaze
From: rickman <gnuarm@gmail.com>
Date: Thu, 22 Oct 2009 11:09:58 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Oct 20, 4:09=A0pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
> rickman <gnu...@gmail.com> wrote:
> > On Oct 20, 3:21?pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
>
> (snip)
>
> >> IBM consistently numbered the MSB 0 on S/360, S/370, XA/370,
> >> ESA/370, ESA/390, and z/Architecture.
>
> (snip)
>
> >> Even more, z/ can operate on code using 64, 31, or 24 bit addressing
> >> as appropriate, and instructions change as the addressing mode changes=
.
> > How are the bits in the address bus numbered? =A0I would find it
> > extremely confusing to deal with an address where the lsb is numbered
> > N where N varies depending on the size of the address range.
>
> If by 'address bus' you mean the physical hardware, that is a separate
> question from the architecture. =A0
>
> Otherwise, the numbering changed in z/, but is internally consistent.
>
> For S/360, 24 bit addresses are in bits 8 to 31 of general registers,
> for example, and the address as stored in the PSW is bits 40 to 63.
>
> z/ extended to 64 bits, so 24 bit addresses are in bits 40 to 63,
> 31 bit in 33 to 63, and 64 bit addresses in bits 0 to 63.
>
> That only comes up in reading the descriptions of the instructions.
>
> In actual coding, (software) one can write a loop in whichever
> way one wants. =A0The hardware will execute it independent of the
> thought process of the programmer.
>
> It never confused me.
>
> -- glen

This discussion has been about the hardware from the first post.  I
don't care much what people do in their heads with a programming
language.  We were talking about connecting different buses in the
hardware.  One was numbered 15 downto 0, IIRC and the other was 0 to
31.  If I understood the OP's problem, he was connecting the two buses
incorrectly.  His real problem was that he was thinking his problem
was something to do with how the language interprets negative numbers
in the various data types.  In reality, I think he was confused about
how to connect a 16 bit bus to a 32 bit bus and preserve sign.

We haven't heard back from him, so I'm not sure how he fixed it.

Rick

Article: 143727
Subject: Re: problem while receiving negative integer in microblaze
From: rickman <gnuarm@gmail.com>
Date: Thu, 22 Oct 2009 11:14:23 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Oct 21, 7:16=A0am, David Brown <da...@westcontrol.removethisbit.com>
wrote:
> glen herrmannsfeldt wrote:
> > rickman <gnu...@gmail.com> wrote:
> >> On Oct 20, 3:21?pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
> > (snip)
>
> >>> IBM consistently numbered the MSB 0 on S/360, S/370, XA/370,
> >>> ESA/370, ESA/390, and z/Architecture.
>
> > (snip)
> >>> Even more, z/ can operate on code using 64, 31, or 24 bit addressing
> >>> as appropriate, and instructions change as the addressing mode change=
s.
>
> >> How are the bits in the address bus numbered? =A0I would find it
> >> extremely confusing to deal with an address where the lsb is numbered
> >> N where N varies depending on the size of the address range.
>
> > If by 'address bus' you mean the physical hardware, that is a separate
> > question from the architecture. =A0
>
> > Otherwise, the numbering changed in z/, but is internally consistent.
>
> > For S/360, 24 bit addresses are in bits 8 to 31 of general registers,
> > for example, and the address as stored in the PSW is bits 40 to 63.
>
> > z/ extended to 64 bits, so 24 bit addresses are in bits 40 to 63,
> > 31 bit in 33 to 63, and 64 bit addresses in bits 0 to 63.
>
> > That only comes up in reading the descriptions of the instructions.
>
> This is "nice and consistent" ?? =A0The bit numbering for the same addres=
s
> varies according to the size of the register, and the significance of a
> bit of a given number varies according to the register, the bit width,
> and the machine variant. =A0I'll agree that much of this is hidden from
> the programmer, and that you can get used to it, but it's still
> inconsistent and it's still messy.
>
> I've dealt with this in the context of PPC microcontrollers - it is a
> big pain in the neck, and it's very easy to get wrong. =A0Virtually
> everything else in the electronics world numbers bits consistently from
> 0 for the LSB - the PPC sticks out like a sore thumb and means that you
> need to invert the bus numbering when connecting it to external memory.
> =A0 Internally, when programming these things, you get the joys of
> figuring out which bits are which in the documentation, and how that
> corresponds to reality. =A0The manual might tell you a hardware register
> is theoretically 64 bits, with the field you are interested in from bits
> 56 to 59. =A0However, perhaps only the lower 32 bits of the register are
> implemented, so the actual bits are 24 to 27. =A0You then have to
> translate this into sensible bit numbers, 4 to 7, so that you can use
> them in software. =A0All in all, reverse bit numbering is a big waste of
> time and effort, and a big cause of mistakes.
>
> And for PPC devices (at least, those I have looked at) with 64-bit
> architectures, the external databus is numbered consistently with the
> 32-bit devices. =A0Thus the LSB of the data and address buses stays at 31=
.
> =A0 So the upper half of the databus runs from D-1 to D-32 as the MSB.
> Internally, of course, the registers are numbered with bit 0 as the MSB
> and bit 63 as the LSB. =A0Thus bit 0 in a data register corresponds to pi=
n
> D-32 on the PPC, matching net D63 on any external memory bus.
>
> Yes, "nice and consistent" is just the phrase...
>
> > In actual coding, (software) one can write a loop in whichever
> > way one wants. =A0The hardware will execute it independent of the
> > thought process of the programmer.
>
> I was under the impression that programming was about getting the
> hardware to execute /dependent/ on the thoughts of the programmer!
>
> > It never confused me.
>
> I've not use the Power architecture, only some PowerPC devices, but I
> have to admit it has confused me on occasion, and irritated and
> frustrated me more often than that.
>
> mvh.,
>
> David

I didn't realize that the microBlaze used a little endian bus
numbering convention.  That is a good reason to avoid it... a small
reason, but a reason nonetheless.

Actually, the main reason to avoid proprietary IP like microBlaze is
the fact that it is proprietary.  I prefer to use one of the available
CPUs that are open source and can be ported to chips from any vendor
or even an ASIC.

Rick

Article: 143728
Subject: Re: Time stability of clock on FPGA board
From: Alex <victous@gmail.com>
Date: Thu, 22 Oct 2009 11:35:00 -0700 (PDT)
Links: << >>  << T >>  << A >>
On 22 =D0=BE=D0=BA=D1=82, 20:27, doug <x...@xx.com> wrote:
> Alex wrote:
> > On 22 =C3=8F=C3=8B=C3=94, 18:19, doug <x...@xx.com> wrote:

> Jitter and stability are two different things. Jitter makes noise on
> the signal. But, generating a signal in an FPGA is not going to be
> quiet anyway as it is not meant for clean signals. Even running a
> clock just thru the FPGA will make it much too noisy for certain
> communications work. We found this out the hard way years ago.

Well, it's helpful.

I am interested - what are other boards available for a student which
could be used for cleaner (than in FPGA-based) signal generation?
For example, would SHARC signal processor boards allow cleaner signal
generation than Xilinx FPGA-based boards?


Article: 143729
Subject: Re: Time stability of clock on FPGA board
From: Alex <victous@gmail.com>
Date: Thu, 22 Oct 2009 11:38:28 -0700 (PDT)
Links: << >>  << T >>  << A >>
On 22 =CF=CB=D4, 20:26, austin <aus...@xilinx.com> wrote:
> DLL jitter,
>
> Is +/- ~ 50 ps about the input frequency.
>
> It has no effect on frequency, whatsoever.
>
> What goes in to a DLL (DCM), comes out. =9AIt is a delay line, with
> taps.
>
> What goes in MUST come out (at exactly the same frequency, with a
> small amount of added jitter).
>
> The DFS (frequency synthesizer) part of the DCM has a bit more jitter
> (nominally 3 times the tap size, + and -), its output frequency is
> also exact (by the M/D ratio specified).
>
> Austin

Okay. I am just a beginner and was easily confused by Ben Jones'
comment earlier in this topic when he wrote that "But I would be
surprised if you ever needed to worry about 50ppm frequency drift in
an FPGA application. The DLL jitter will be an order of magnitude
greater than that... "

Article: 143730
Subject: Re: External IO Port without using Xilinx's GPIO IP
From: "hvo" <hai.vo@synrad.com>
Date: Thu, 22 Oct 2009 14:14:35 -0500
Links: << >>  << T >>  << A >>

Thanks for your comments.

I guess I don't like Xilinx's GPIO IP very much because they take up a lot
of slices to implement (as far as GPIO goes).  My application requires a
few GPIO IPs along with other IPs, and I find that Im running out of room
on my Spartan 3AN device.  

Im new at this, so im sure theres ways around it. But for a newbee like me,
I wish there were simple GPIO IPs that doesn't take a lot of logic to
implement.

I guess this is where custom IP comes in handy.

Best Regards
	   
					
---------------------------------------		
This message was sent using the comp.arch.fpga web interface on
http://www.FPGARelated.com

Article: 143731
Subject: Re: Time stability of clock on FPGA board
From: Alex <victous@gmail.com>
Date: Thu, 22 Oct 2009 12:41:52 -0700 (PDT)
Links: << >>  << T >>  << A >>
On 22 =D0=BE=D0=BA=D1=82, 23:23, doug <x...@xx.com> wrote:
> Alex wrote:
> > On 22 =D0=BE=D0=BA=D1=82, 20:27, doug <x...@xx.com> wrote:
>
> >>Alex wrote:
>
> >>>On 22 =C3=8F=C3=8B=C3=94, 18:19, doug <x...@xx.com> wrote:
>
> >>Jitter and stability are two different things. Jitter makes noise on
> >>the signal. But, generating a signal in an FPGA is not going to be
> >>quiet anyway as it is not meant for clean signals. Even running a
> >>clock just thru the FPGA will make it much too noisy for certain
> >>communications work. We found this out the hard way years ago.
>
> > Well, it's helpful.
>
> > I am interested - what are other boards available for a student which
> > could be used for cleaner (than in FPGA-based) signal generation?
> > For example, would SHARC signal processor boards allow cleaner signal
> > generation than Xilinx FPGA-based boards?
>
> The issue on any of the complex digital circuits is that the
> transitions of the incoming clock get modulated by the digital
> noise from the other circuits. This is of very little importance
> for digital work other than introducing some jitter. It is
> very important for generating clean analog waveforms. If you
> want a relatively clean programmable oscillator look at the
> Analog Devices DDS line. Their parts work very well and
> the programming is pretty easy.

Thanks for advice!

Article: 143732
Subject: feof, fseek, ftell on XilFATFS
From: yuebing <jiangyuebing@gmail.com>
Date: Thu, 22 Oct 2009 13:21:41 -0700 (PDT)
Links: << >>  << T >>  << A >>
How does XilFATFS support the above function?

Article: 143733
Subject: Re: Time stability of clock on FPGA board
From: doug <xx@xx.com>
Date: Thu, 22 Oct 2009 12:23:13 -0800
Links: << >>  << T >>  << A >>


Alex wrote:

> On 22 окт, 20:27, doug <x...@xx.com> wrote:
> 
>>Alex wrote:
>>
>>>On 22 ÏËÔ, 18:19, doug <x...@xx.com> wrote:
> 
> 
>>Jitter and stability are two different things. Jitter makes noise on
>>the signal. But, generating a signal in an FPGA is not going to be
>>quiet anyway as it is not meant for clean signals. Even running a
>>clock just thru the FPGA will make it much too noisy for certain
>>communications work. We found this out the hard way years ago.
> 
> 
> Well, it's helpful.
> 
> I am interested - what are other boards available for a student which
> could be used for cleaner (than in FPGA-based) signal generation?
> For example, would SHARC signal processor boards allow cleaner signal
> generation than Xilinx FPGA-based boards?
> 
The issue on any of the complex digital circuits is that the
transitions of the incoming clock get modulated by the digital
noise from the other circuits. This is of very little importance
for digital work other than introducing some jitter. It is
very important for generating clean analog waveforms. If you
want a relatively clean programmable oscillator look at the
Analog Devices DDS line. Their parts work very well and
the programming is pretty easy.

Article: 143734
Subject: Re: Time stability of clock on FPGA board
From: -jg <jim.granville@gmail.com>
Date: Thu, 22 Oct 2009 15:51:59 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Oct 23, 4:00=A0am, Alex <vict...@gmail.com> wrote:
> Hence, I am interested - if I will use a clock with, for example,
> 0.001ppm time stability then would it be possible to generate few MHz
> frequency in 0.1Hz steps? Would DLL jitter prevent this or not? (I am
> going to use Spartan3E 1600E Microblaze Development Kit).

You should explain what frequencies you want, as talking in ppm on one
hand, and 0.1Hz on the other  does not help.

Also, is absolute precision important, or do you simply want a 0.1Hz
step size

50ppm numbers are the absolute error, and not the stability.
Stability is usually a LOT better than that, and then there is jitter
to consider, but a good Xtal will be a few ps, or just under 1 ps

You are also better to think in the time-domain, rather than
frequency.

So, if we take  your "generate few MHz  frequency in 0.1Hz steps"
and reality check 1000000Hz with 1000000.1Hz,  the actual
period difference you are asking for, is 10e-14, or 100 femto seconds
(if you really want every cycle to be 1000000.1 Hz).

Now, compare that with the Austin's DLL jitter of 50ps, or even a
good Xtal Osc of 2ps, and you can see the problem.

So, having decided every-cycle precision is not practical, you hve to
decide over what time you need this 0.1Hz.
Suppose you need it over 100ms, then you can generate 99,999 cycles of
1.00us, and one cycle of



Article: 143735
Subject: Re: Time stability of clock on FPGA board
From: -jg <jim.granville@gmail.com>
Date: Thu, 22 Oct 2009 16:03:36 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Oct 23, 11:51=A0am, -jg <jim.granvi...@gmail.com> wrote:
> So, having decided every-cycle precision is not practical, you have to
> decide over what time you need this 0.1Hz ?
> Suppose you need it over 100ms, then you can generate 99,999 cycles of
> 1.00us, and one cycle of

( oops, Hit the wrong button...)
Finishing that example: in a pure digital domain

For a 100ms time average, of your 1000000.1 Hz, we generate
99,999 cycles of 1,00us and one cycle 10ns less
Frequency is then Cycles.Time  =3D

100000/(99999*1.0u + (1u-10n)) =3D 1000000.10000001

So, you _can_ generate 1MHz to 0.1Hz increments, over multiples of
greater than 100ms, with a 10ns timebase.
That certainly is FPGA doable.

Over 10.00 seconds, you will get 10000001 edges (etc)

-jg

Article: 143736
Subject: Re: External IO Port without using Xilinx's GPIO IP
From: Antti <antti.lukats@googlemail.com>
Date: Thu, 22 Oct 2009 23:15:21 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Oct 22, 10:14=A0pm, "hvo" <hai...@synrad.com> wrote:
> Thanks for your comments.
>
> I guess I don't like Xilinx's GPIO IP very much because they take up a lo=
t
> of slices to implement (as far as GPIO goes). =A0My application requires =
a
> few GPIO IPs along with other IPs, and I find that Im running out of room
> on my Spartan 3AN device. =A0
>
> Im new at this, so im sure theres ways around it. But for a newbee like m=
e,
> I wish there were simple GPIO IPs that doesn't take a lot of logic to
> implement.
>
> I guess this is where custom IP comes in handy.
>
> Best Regards
>
> --------------------------------------- =A0 =A0 =A0 =A0
> This message was sent using the comp.arch.fpga web interface onhttp://www=
.FPGARelated.com

the smalles and easiest is to use FSL bus
it allows very small resource usaga GPIO like io access, I have done
it many projects
some microfpga designs as example use "FSL ASIO" IP core what is
configurable IP
with 1 to n (n can be 1000+) I/O and connection to FSL
the FEATURE (or problem) is of the ASIO core is that you can access
GPIO pins
only one at a time, what is sometimes nice, and sometimes a problem

Antti
PS it seems Antti-Brain october issues is going to be much more pages
then usual
i hope the content is of some interest too







Article: 143737
Subject: Re: problem while receiving negative integer in microblaze
From: Goran_Bilski <goran.bilski@xilinx.com>
Date: Thu, 22 Oct 2009 23:42:28 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Oct 22, 8:14=A0pm, rickman <gnu...@gmail.com> wrote:
> On Oct 21, 7:16=A0am, David Brown <da...@westcontrol.removethisbit.com>
> wrote:
>
>
>
>
>
> > glen herrmannsfeldt wrote:
> > > rickman <gnu...@gmail.com> wrote:
> > >> On Oct 20, 3:21?pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrot=
e:
> > > (snip)
>
> > >>> IBM consistently numbered the MSB 0 on S/360, S/370, XA/370,
> > >>> ESA/370, ESA/390, and z/Architecture.
>
> > > (snip)
> > >>> Even more, z/ can operate on code using 64, 31, or 24 bit addressin=
g
> > >>> as appropriate, and instructions change as the addressing mode chan=
ges.
>
> > >> How are the bits in the address bus numbered? =A0I would find it
> > >> extremely confusing to deal with an address where the lsb is numbere=
d
> > >> N where N varies depending on the size of the address range.
>
> > > If by 'address bus' you mean the physical hardware, that is a separat=
e
> > > question from the architecture. =A0
>
> > > Otherwise, the numbering changed in z/, but is internally consistent.
>
> > > For S/360, 24 bit addresses are in bits 8 to 31 of general registers,
> > > for example, and the address as stored in the PSW is bits 40 to 63.
>
> > > z/ extended to 64 bits, so 24 bit addresses are in bits 40 to 63,
> > > 31 bit in 33 to 63, and 64 bit addresses in bits 0 to 63.
>
> > > That only comes up in reading the descriptions of the instructions.
>
> > This is "nice and consistent" ?? =A0The bit numbering for the same addr=
ess
> > varies according to the size of the register, and the significance of a
> > bit of a given number varies according to the register, the bit width,
> > and the machine variant. =A0I'll agree that much of this is hidden from
> > the programmer, and that you can get used to it, but it's still
> > inconsistent and it's still messy.
>
> > I've dealt with this in the context of PPC microcontrollers - it is a
> > big pain in the neck, and it's very easy to get wrong. =A0Virtually
> > everything else in the electronics world numbers bits consistently from
> > 0 for the LSB - the PPC sticks out like a sore thumb and means that you
> > need to invert the bus numbering when connecting it to external memory.
> > =A0 Internally, when programming these things, you get the joys of
> > figuring out which bits are which in the documentation, and how that
> > corresponds to reality. =A0The manual might tell you a hardware registe=
r
> > is theoretically 64 bits, with the field you are interested in from bit=
s
> > 56 to 59. =A0However, perhaps only the lower 32 bits of the register ar=
e
> > implemented, so the actual bits are 24 to 27. =A0You then have to
> > translate this into sensible bit numbers, 4 to 7, so that you can use
> > them in software. =A0All in all, reverse bit numbering is a big waste o=
f
> > time and effort, and a big cause of mistakes.
>
> > And for PPC devices (at least, those I have looked at) with 64-bit
> > architectures, the external databus is numbered consistently with the
> > 32-bit devices. =A0Thus the LSB of the data and address buses stays at =
31.
> > =A0 So the upper half of the databus runs from D-1 to D-32 as the MSB.
> > Internally, of course, the registers are numbered with bit 0 as the MSB
> > and bit 63 as the LSB. =A0Thus bit 0 in a data register corresponds to =
pin
> > D-32 on the PPC, matching net D63 on any external memory bus.
>
> > Yes, "nice and consistent" is just the phrase...
>
> > > In actual coding, (software) one can write a loop in whichever
> > > way one wants. =A0The hardware will execute it independent of the
> > > thought process of the programmer.
>
> > I was under the impression that programming was about getting the
> > hardware to execute /dependent/ on the thoughts of the programmer!
>
> > > It never confused me.
>
> > I've not use the Power architecture, only some PowerPC devices, but I
> > have to admit it has confused me on occasion, and irritated and
> > frustrated me more often than that.
>
> > mvh.,
>
> > David
>
> I didn't realize that the microBlaze used a little endian bus
> numbering convention. =A0That is a good reason to avoid it... a small
> reason, but a reason nonetheless.
>
> Actually, the main reason to avoid proprietary IP like microBlaze is
> the fact that it is proprietary. =A0I prefer to use one of the available
> CPUs that are open source and can be ported to chips from any vendor
> or even an ASIC.
>
> Rick- Hide quoted text -
>
> - Show quoted text -

Hi,

MicroBlaze use big-endian byte-ordering and big-endian bit ordering.
This is a legacy from PowerPC and CoreConnect bus.
It's not only PowerPC who uses big-endian ordering.

As much as the msb bit number changes for big-endian so does the lsb
bit number for little-endian.

In my earlier years before MicroBlaze I only used little-endian bit
ordering and I had to change to big-endian for MicroBlaze.
It took some time but now when I define a vector bus it tends to be
big-endian.
I don't have much of a preference anymore. it's just two different
ways of defining a vector.

I do however prefer big-endian byte order since when dumping bytes
from memory will show the word in the right order.
We tend to write numbers with the most significant numbers to the left
and that is how big-endian is storing bytes within a word.

But I'm not sure if big-endian byte order and little-endian bit order
is a good idea. It might be too confusing.

G=F6ran

Article: 143738
Subject: Re: CPLD/FPGA with Linux
From: "HT-Lab" <hans64@ht-lab.com>
Date: Fri, 23 Oct 2009 09:15:32 +0100
Links: << >>  << T >>  << A >>

"Andy Botterill" <andy@plymouth2.demon.co.uk> wrote in message 
news:4ae0966d$0$17520$bed64819@gradwell.net...
> Scorpiion wrote:
..
>
> The ISIM simulator does work under linux.
>
> I have no knowledge of VHDL simulators for linux.
>

It is called Modelsim DE (just released)

The good news is that it includes PSL/SVA so assertions are no longer reserved 
for the big boys :-)

Hans
www.ht-lab.com



> The officially supported o/s is RHEL and I think vista.
>
> Support for the design process I don't know. Andy
>>
>> I have looked at some of Xilinks and Alteras homepages and it seams that
>> they have software for Linux. But it would be good to hear from someone
>> with experince how the different software packages work? (if some company
>> have better software than other, or someones software is better for the
>> Linux platform)
>>
>> I'm just not sure where to start and some genereal tips on Linux and
>> CPLD/FPGAs would also be good to hear... :)
>>
>> Regards, Robert
>> 


Article: 143739
Subject: Re: CPLD/FPGA with Linux
From: Habib Bouaziz-Viallet <h.bouazizviallet@free.fr>
Date: 23 Oct 2009 08:27:57 GMT
Links: << >>  << T >>  << A >>
Le Thu, 22 Oct 2009 10:42:15 -0700, austin a écrit :

> Programming tools (the JTAG programming cable) used with Linux are
> always a bit tough to get to work (just read the posts on the subject)
> as support of USB isn't as trivial as it is with 'Windoze.'
Are you sure of that ? Xilinx windrv ported to linux is a nightmare. I'm 
using this library <http://www.rmdir.de/~michael/xilinx/> fairly support 
cable III, cableIV and this one http://www.digilentinc.com/Products/
Detail.cfm?NavPath=2,395,716&Prod=XUP-USB-JTAG i'm using for the moment.

You can read the XAPP502 if you want to deeply embed programming CPLD/
FPGA. As an example PROGRAM, CCLK, DIN, INIT, DONE signals are quite 
easily driven by a microcontroller to do the job with a .bit or .rbt file.

After a discussion with M. Delorie in this very ng, i found XAPP058 a bit 
complicated for my needs ...

Habib





Article: 143740
Subject: Re: problem while receiving negative integer in microblaze
From: David Brown <david@westcontrol.removethisbit.com>
Date: Fri, 23 Oct 2009 10:32:50 +0200
Links: << >>  << T >>  << A >>
Goran_Bilski wrote:
> On Oct 22, 8:14 pm, rickman <gnu...@gmail.com> wrote:
>> On Oct 21, 7:16 am, David Brown <da...@westcontrol.removethisbit.com>

<snip to save space>

>> I didn't realize that the microBlaze used a little endian bus
>> numbering convention.  That is a good reason to avoid it... a small
>> reason, but a reason nonetheless.
>>

I don't actually know much about the MicroBlaze - I can only refer to 
the PPC, which I have used (not in FPGAs).  But I'd agree with you here 
- having big-endian bit numbering would definitely count against the 
MicroBlaze as far as I am concerned.  I think it would be especially 
painful in FPGA designs, since tools can often automatically connect up 
buses (at least, that was the case when I did some work with the Nios 
and Quartus a few years ago).  If you've got some components with 
big-endian bit numbering, and some with small-endian bit numbering, 
something's going to get mixed up pretty quickly.

>> Actually, the main reason to avoid proprietary IP like microBlaze is
>> the fact that it is proprietary.  I prefer to use one of the available
>> CPUs that are open source and can be ported to chips from any vendor
>> or even an ASIC.
>>

That's another discussion entirely - good points, but they need their 
own branch or thread.

>> Rick- Hide quoted text -
>>
>> - Show quoted text -
> 
> Hi,
> 
> MicroBlaze use big-endian byte-ordering and big-endian bit ordering.
> This is a legacy from PowerPC and CoreConnect bus.
> It's not only PowerPC who uses big-endian ordering.
> 

The PPC is perhaps not alone in using big-endian bit numbering, but it 
is certainly one of only a very few processors.

All the 32-bit processor families that I have worked with are 
big-endian.  This includes MIPS, PPC, ColdFire (68k), AVR32 and Nios. 
Some of these (like MIPS and PPC) can handle little-endian data to some 
extent, but are naturally big-endian.  The only two major little-endian 
32-bit architectures I can think of are ARM and x86.

I don't know why most "modern" designs are big-endian.  There are good 
reasons why older CISC designs (such as VAX and x86) are little-endian - 
for one thing, it makes it easier to write multi-byte arithmetic 
functions, and it makes it easier to convert integer sizes.  There seems 
to be a fair correlation between RISC and big-endian - certainly when 
you move from an architecture oriented around accessing memory, working 
with 8 bits at a time to an architecture oriented around keeping data in 
registers, and working with a full 32-bit register at a time, then the 
key advantages of little-endian ordering are no longer relevant.

However, of those architectures, the only one which uses big-endian bit 
numbering is the PPC.

Preferences and experiences are, of course, personal.  Some people have 
strong opinions about which endianness they prefer (just ask the 
Lilliputeans), others are happy to mix and match.

> As much as the msb bit number changes for big-endian so does the lsb
> bit number for little-endian.
> 
> In my earlier years before MicroBlaze I only used little-endian bit
> ordering and I had to change to big-endian for MicroBlaze.
> It took some time but now when I define a vector bus it tends to be
> big-endian.
> I don't have much of a preference anymore. it's just two different
> ways of defining a vector.
> 
> I do however prefer big-endian byte order since when dumping bytes
> from memory will show the word in the right order.
> We tend to write numbers with the most significant numbers to the left
> and that is how big-endian is storing bytes within a word.
> 
> But I'm not sure if big-endian byte order and little-endian bit order
> is a good idea. It might be too confusing.
> 

It's the most common arrangement, in my experience.

> Gran

Article: 143741
Subject: Re: CPLD/FPGA with Linux
From: Uwe Bonnes <bon@elektron.ikp.physik.tu-darmstadt.de>
Date: Fri, 23 Oct 2009 08:46:46 +0000 (UTC)
Links: << >>  << T >>  << A >>
austin <austin@xilinx.com> wrote:

> Programming tools (the JTAG programming cable) used with Linux are
> always a bit tough to get to work (just read the posts on the subject)
> as support of USB isn't as trivial as it is with 'Windoze.'

Xc3sprog at sourceforge is also supposed to work out of the box for many
cable and devices. I am interessted in cases where it doesn't.

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

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

Article: 143742
Subject: Re: Time stability of clock on FPGA board
From: Ben Jones <benjjuk@gmail.com>
Date: Fri, 23 Oct 2009 03:47:07 -0700 (PDT)
Links: << >>  << T >>  << A >>
> Okay. I am just a beginner and was easily confused by Ben Jones'
> comment earlier in this topic when he wrote that "But I would be
> surprised if you ever needed to worry about 50ppm frequency drift in
> an FPGA application. The DLL jitter will be an order of magnitude
> greater than that... "

Hi Alex,

Sorry to confuse you!

What I meant was that in a typical FPGA design, one or more of your
clocks is likely to come from a DLL-based clock management block,
which usually has an output jitter on the order of 100s of
picoseconds. That is, even if the cycle time of your clock is 10ns
when averaged over a few microseconds, the actual time elapsed between
one active edge and the next might vary by 1% or more. This is
certainly not the same as frequency accuracy/stability - but if your
task is to produce a highly precise clock output, it's probably a
bigger barrier to your application.

I didn't go to time school, though, so don't pay *too* much attention
to what I say. :-)

       -Ben-

Article: 143743
Subject: Re: Time stability of clock on FPGA board
From: nico@puntnl.niks (Nico Coesel)
Date: Fri, 23 Oct 2009 11:44:36 GMT
Links: << >>  << T >>  << A >>
doug <xx@xx.com> wrote:

>
>
>Nico Coesel wrote:
>
>> doug <xx@xx.com> wrote:
>> 
>> 
>>>
>>>Alex wrote:
>>>
>>>
>>>>Hi Ben,
>>>>
>>>>Thank you for reply.
>>>>
>>>>I actually worry about clock's time stability because I want to design
>>>>FPGA-based oscillator whose frequency can be set in 0.1 Hz steps.
>>>>Whether 50 ppm clock's stability is good enough to be used for such
>>>>design?
>>>
>>>You need to look at the difference between accuracy and resolution and
>>>stability.  A DDS will give you a resolution proportional to the number
>>>of bits in the accumulator. The accuracy of the divide ratio is
>>>absolute. The accuracy of the output frequency is proportional to the
>>>accuracy of the oscillator.  If you output a 10MHz signal with a
>>>reference oscillator whose stability over temperature and time is 50ppm,
>>>the output frequency can vary by 500Hz. At a couple of ppm per degree,
>>>the frequency would wander perhaps 20Hz per degree. This means a .1Hz
>>>resolution is not very useful.  For this to be meaninful, you would
>>>need a stability of .01ppm.  If, however, you are doing this at 20KHz,
>>>then the .1Hz corresponds to 5ppm and it is not so awful to use the
>>>50ppm stability oscillator.
>> 
>> 
>> Sorry, but this is all wrong!
>
>No, is is just fine.

No, in your claims the drift gets worst at lower frequencies. However,
ppm as a relative error indicator is constant across all output
frequencies so your claims must be false.

-- 
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
                     "If it doesn't fit, use a bigger hammer!"
--------------------------------------------------------------

Article: 143744
Subject: Re: Time stability of clock on FPGA board
From: nico@puntnl.niks (Nico Coesel)
Date: Fri, 23 Oct 2009 11:49:03 GMT
Links: << >>  << T >>  << A >>
-jg <jim.granville@gmail.com> wrote:

>On Oct 23, 11:51=A0am, -jg <jim.granvi...@gmail.com> wrote:
>> So, having decided every-cycle precision is not practical, you have to
>> decide over what time you need this 0.1Hz ?
>> Suppose you need it over 100ms, then you can generate 99,999 cycles of
>> 1.00us, and one cycle of
>
>( oops, Hit the wrong button...)
>Finishing that example: in a pure digital domain
>
>For a 100ms time average, of your 1000000.1 Hz, we generate
>99,999 cycles of 1,00us and one cycle 10ns less
>Frequency is then Cycles.Time  =3D
>
>100000/(99999*1.0u + (1u-10n)) =3D 1000000.10000001
>
>So, you _can_ generate 1MHz to 0.1Hz increments, over multiples of
>greater than 100ms, with a 10ns timebase.
>That certainly is FPGA doable.

It certainly is. Years ago I build a DPLL in an FPGA that way for
synchronising to an E1 line. It has a range of +/- 200ppm in less than
0.5ppm steps. Its just a matter of skipping or inserting extra clock
cycles each frame.

-- 
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
                     "If it doesn't fit, use a bigger hammer!"
--------------------------------------------------------------

Article: 143745
Subject: Re: problem while receiving negative integer in microblaze
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Fri, 23 Oct 2009 12:19:31 +0000 (UTC)
Links: << >>  << T >>  << A >>
Goran_Bilski <goran.bilski@xilinx.com> wrote:
(snip)
 
> MicroBlaze use big-endian byte-ordering and big-endian bit ordering.
> This is a legacy from PowerPC and CoreConnect bus.
> It's not only PowerPC who uses big-endian ordering.
 
> As much as the msb bit number changes for big-endian so does the lsb
> bit number for little-endian.
 
(snip) 
> I do however prefer big-endian byte order since when dumping bytes
> from memory will show the word in the right order.
> We tend to write numbers with the most significant numbers to the left
> and that is how big-endian is storing bytes within a word.

The VAX/VMS DUMP program prints the HEX data right to left, and
the ASCII data left to right with the address in the middle.
Big endian avoids strange solutions like that.

-- glen 

Article: 143746
Subject: Re: Time stability of clock on FPGA board
From: doug <xx@xx.com>
Date: Fri, 23 Oct 2009 09:34:33 -0800
Links: << >>  << T >>  << A >>


Nico Coesel wrote:

> doug <xx@xx.com> wrote:
> 
> 
>>
>>Nico Coesel wrote:
>>
>>
>>>doug <xx@xx.com> wrote:
>>>
>>>
>>>
>>>>Alex wrote:
>>>>
>>>>
>>>>
>>>>>Hi Ben,
>>>>>
>>>>>Thank you for reply.
>>>>>
>>>>>I actually worry about clock's time stability because I want to design
>>>>>FPGA-based oscillator whose frequency can be set in 0.1 Hz steps.
>>>>>Whether 50 ppm clock's stability is good enough to be used for such
>>>>>design?
>>>>
>>>>You need to look at the difference between accuracy and resolution and
>>>>stability.  A DDS will give you a resolution proportional to the number
>>>>of bits in the accumulator. The accuracy of the divide ratio is
>>>>absolute. The accuracy of the output frequency is proportional to the
>>>>accuracy of the oscillator.  If you output a 10MHz signal with a
>>>>reference oscillator whose stability over temperature and time is 50ppm,
>>>>the output frequency can vary by 500Hz. At a couple of ppm per degree,
>>>>the frequency would wander perhaps 20Hz per degree. This means a .1Hz
>>>>resolution is not very useful.  For this to be meaninful, you would
>>>>need a stability of .01ppm.  If, however, you are doing this at 20KHz,
>>>>then the .1Hz corresponds to 5ppm and it is not so awful to use the
>>>>50ppm stability oscillator.
>>>
>>>
>>>Sorry, but this is all wrong!
>>
>>No, is is just fine.
> 
> 
> No, in your claims the drift gets worst at lower frequencies.

No, there is no claim the drift get worse at lower frequencies.
Read the sentence again.

  However,
> ppm as a relative error indicator is constant across all output
> frequencies so your claims must be false.

The calculations were fine.
> 

Article: 143747
Subject: Re: Time stability of clock on FPGA board
From: doug <xx@xx.com>
Date: Fri, 23 Oct 2009 09:40:16 -0800
Links: << >>  << T >>  << A >>


Nico Coesel wrote:

> -jg <jim.granville@gmail.com> wrote:
> 
> 
>>On Oct 23, 11:51=A0am, -jg <jim.granvi...@gmail.com> wrote:
>>
>>>So, having decided every-cycle precision is not practical, you have to
>>>decide over what time you need this 0.1Hz ?
>>>Suppose you need it over 100ms, then you can generate 99,999 cycles of
>>>1.00us, and one cycle of
>>
>>( oops, Hit the wrong button...)
>>Finishing that example: in a pure digital domain
>>
>>For a 100ms time average, of your 1000000.1 Hz, we generate
>>99,999 cycles of 1,00us and one cycle 10ns less
>>Frequency is then Cycles.Time  =3D
>>
>>100000/(99999*1.0u + (1u-10n)) =3D 1000000.10000001
>>
>>So, you _can_ generate 1MHz to 0.1Hz increments, over multiples of
>>greater than 100ms, with a 10ns timebase.
>>That certainly is FPGA doable.
> 
> 
> It certainly is. Years ago I build a DPLL in an FPGA that way for
> synchronising to an E1 line. It has a range of +/- 200ppm in less than
> 0.5ppm steps. Its just a matter of skipping or inserting extra clock
> cycles each frame.
> 
This works fine for locking to a fixed frequency over a narrow range
and many of us have used it.  The deficiency of it is that it is fine
for digital clocks but is bad for analog signals.  For generating
arbitrary frequencies, you are better off using a DDS.  The DDS is even
available as a coregen element for Xilinx (the digital part anyway).

Article: 143748
Subject: Re: Time stability of clock on FPGA board
From: Alex <victous@gmail.com>
Date: Fri, 23 Oct 2009 11:59:26 -0700 (PDT)
Links: << >>  << T >>  << A >>
On 23 =CF=CB=D4, 13:47, Ben Jones <benj...@gmail.com> wrote:
> > Okay. I am just a beginner and was easily confused by Ben Jones'
> > comment earlier in this topic when he wrote that "But I would be
> > surprised if you ever needed to worry about 50ppm frequency drift in
> > an FPGA application. The DLL jitter will be an order of magnitude
> > greater than that... "
>
> Hi Alex,
>
> Sorry to confuse you!
>
> What I meant was that in a typical FPGA design, one or more of your
> clocks is likely to come from a DLL-based clock management block,
> which usually has an output jitter on the order of 100s of
> picoseconds. That is, even if the cycle time of your clock is 10ns
> when averaged over a few microseconds, the actual time elapsed between
> one active edge and the next might vary by 1% or more. This is
> certainly not the same as frequency accuracy/stability - but if your
> task is to produce a highly precise clock output, it's probably a
> bigger barrier to your application.
>
> I didn't go to time school, though, so don't pay *too* much attention
> to what I say. :-)
>
> =9A =9A =9A =9A-Ben-

Okay, Ben! Thanks a lot for helpful replies. :-)


Article: 143749
Subject: Re: Time stability of clock on FPGA board
From: Alex <victous@gmail.com>
Date: Fri, 23 Oct 2009 12:12:04 -0700 (PDT)
Links: << >>  << T >>  << A >>
On 23 =CF=CB=D4, 02:03, -jg <jim.granvi...@gmail.com> wrote:
> On Oct 23, 11:51=9Aam, -jg <jim.granvi...@gmail.com> wrote:
>
> > So, having decided every-cycle precision is not practical, you have to
> > decide over what time you need this 0.1Hz ?
> > Suppose you need it over 100ms, then you can generate 99,999 cycles of
> > 1.00us, and one cycle of
>
> ( oops, Hit the wrong button...)
> Finishing that example: in a pure digital domain
>
> For a 100ms time average, of your 1000000.1 Hz, we generate
> 99,999 cycles of 1,00us and one cycle 10ns less
> Frequency is then Cycles.Time =9A=3D
>
> 100000/(99999*1.0u + (1u-10n)) =3D 1000000.10000001
>
> So, you _can_ generate 1MHz to 0.1Hz increments, over multiples of
> greater than 100ms, with a 10ns timebase.
> That certainly is FPGA doable.
>
> Over 10.00 seconds, you will get 10000001 edges (etc)
>
>
I will need that stability over time scale larger than 100ms indeed.
Thank you for helpful reply!



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