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 138500

Article: 138500
Subject: Re: mb-gcc producing incorrect code ???
From: luudee <rudolf.usselmann@gmail.com>
Date: Wed, 25 Feb 2009 03:00:23 -0800 (PST)
Links: << >>  << T >>  << A >>
On Feb 25, 4:08=A0pm, hal-use...@ip-64-139-1-69.sjc.megapath.net (Hal
Murray) wrote:
> >I know that MB is big-endian, vs my linux box being little-endian.
> >But shouldn't the C compiler produce the same results, regardless
> >of the system endianness ?
>
> Which one is right?
>
> If the compiler could do the "right" thing, we wouldn't have
> endian wars.

Well, clearly the "right thing", imho, would be to be consistent.

rudi



Article: 138501
Subject: Re: Fm digital baseband demodulation
From: My Name <myemail@a_domain.com>
Date: Wed, 25 Feb 2009 04:30:33 -0800
Links: << >>  << T >>  << A >>

Thanks!!!I was confused with the division part of  demodulation
algorithm you mentioned.But it's true i think that the amplitude of
I^2+Q^2 is always a constant due to the thing that I and Q have a
difference in phase of &#960;, so like the common expression
cos(f)^2+sin(f)^2=1 the amplitude of  I^2+Q^2 must be a constant.


-- 
xristos
------------------------------------------------------------------------
xristos's Profile: http://www.fpgacentral.com/group/member.php?userid=15
View this thread: http://www.fpgacentral.com/group/showthread.php?t=88112


Article: 138502
Subject: Re: mb-gcc producing incorrect code ???
From: Brian Drummond <brian_drummond@btconnect.com>
Date: Wed, 25 Feb 2009 12:58:41 +0000
Links: << >>  << T >>  << A >>
On Wed, 25 Feb 2009 03:00:23 -0800 (PST), luudee <rudolf.usselmann@gmail.com>
wrote:

>On Feb 25, 4:08 pm, hal-use...@ip-64-139-1-69.sjc.megapath.net (Hal
>Murray) wrote:
>> >I know that MB is big-endian, vs my linux box being little-endian.
>> >But shouldn't the C compiler produce the same results, regardless
>> >of the system endianness ?
>>
>> Which one is right?
>>
>> If the compiler could do the "right" thing, we wouldn't have
>> endian wars.
>
>Well, clearly the "right thing", imho, would be to be consistent.

I think you'd need a better language than C for that.
Ada's representation clauses come to mind - YOU define the data layout,
exactly as the hardware does it.

But porting Gnat to microblaze is probably non-trivial. (There is supposedly a
PPC port, but I haven't heard of anyone using it with EDK)

Meanwhile, faking it with shifts and masks is likely to be the best bet for
portablility.

- Brian

Article: 138503
Subject: VHDL programmer position available in Northern NJ-- westwood, NJ
From: jleslie48 <jon@jonathanleslie.com>
Date: Wed, 25 Feb 2009 06:47:32 -0800 (PST)
Links: << >>  << T >>  << A >>
DHPC, a leader in military sensor technology development, has openings
for experienced software/hardware developers in several applications.
The ideal candidate will have 3+ years experience in systems level
programming using VHDL and FPGA in a DSP environment, using the ISE
Project Navigator environment on Xilinx Virtex chipset.   Programming
with C/C++ using Code Composer, UNIX, Dos, and Windows experience is
also desirable.   Shell scripting is a plus.  In addition any
experience with real time programming environments, FIFO/LIFO queuing
theory, and discrete memory allocation issues are a plus.  The
positions will challenge the programmers ability to creatively problem
solve and implement designed algorithms.  This is a full time
position.  All candidates must be US citizens and capable of getting
government security clearance (read: no police record)

Please forward resumes to:

jleslie@dhpconsultants.com


Article: 138504
Subject: virtex 5 columns
From: colin <colin_toogood@yahoo.com>
Date: Wed, 25 Feb 2009 06:51:38 -0800 (PST)
Links: << >>  << T >>  << A >>
Hello

I have a new virtex 5 design with a lot of IO going at the same speed.
I've been told to put all this IO on the same column. Also I can then
use the DCI bank cascading.

Does anyone know the logic behind the bank numbering? I can't find any
data on which banks are in which column.

Colin

Article: 138505
Subject: Can Xilinx IST automatically detect non-compatible library?
From: Weng Tianxiang <wtxwtx@gmail.com>
Date: Wed, 25 Feb 2009 08:05:55 -0800 (PST)
Links: << >>  << T >>  << A >>
Hi,
When I was generating my code, I didn't know what exact Xilinx chip
may be used so that I selected Virtex V chip as my target one time.
During the development, I might have tried to generate libraries with
Virtex II chips because I have many Virtex II libraries ready to use.
It led to the situation that I really don't know which library belongs
to which chip. For simulations, it doesn't matter. But now I am trying
to implement my design on Virtex II chip, the problem comes clear: if
all libraries used in my simulation are for Virtex II? I can't answer
the question.

So I would like to ask if Xilinx IST can automatically detect an error
when a Virtex V chip library is used for a Virtex II chip project. I
think it is. But to reduce risks of errors, I would like to ask
experienced persons for a positive answer without any guess.

Thank you.

Weng


Article: 138506
Subject: Re: Can Xilinx IST automatically detect non-compatible library?
From: LittleAlex <alex.louie@email.com>
Date: Wed, 25 Feb 2009 09:30:47 -0800 (PST)
Links: << >>  << T >>  << A >>
On Feb 25, 9:05 am, Weng Tianxiang <wtx...@gmail.com> wrote:
> Hi,
> When I was generating my code, I didn't know what exact Xilinx chip
> may be used so that I selected Virtex V chip as my target one time.
> During the development, I might have tried to generate libraries with
> Virtex II chips because I have many Virtex II libraries ready to use.
> It led to the situation that I really don't know which library belongs
> to which chip. For simulations, it doesn't matter. But now I am trying
> to implement my design on Virtex II chip, the problem comes clear: if
> all libraries used in my simulation are for Virtex II? I can't answer
> the question.
>
> So I would like to ask if Xilinx IST can automatically detect an error
> when a Virtex V chip library is used for a Virtex II chip project. I
> think it is. But to reduce risks of errors, I would like to ask
> experienced persons for a positive answer without any guess.
>
> Thank you.
>
> Weng

Simulation libraries and Synthesis libraries are different.

XST does check synthesis libraries.  PAR will fail if the wrong
libraries are linked.

AL

Article: 138507
Subject: Re: Configure FPGA via PCIe
From: rickman <gnuarm@gmail.com>
Date: Wed, 25 Feb 2009 10:05:04 -0800 (PST)
Links: << >>  << T >>  << A >>
On Feb 25, 4:49 am, Allan Herriman <allanherri...@hotmail.com> wrote:
> rickman <gnu...@gmail.com> wrote innews:3774b465-11f4-4daa-aee7-d44f72fce9a6@n20g2000vba.googlegroups.com:
>
>
>
> > On Feb 24, 8:27 am, Allan Herriman <allanherri...@hotmail.com> wrote:
> >> "Krzysztof Kepa" <nospam_blond...@poczta.fm> wrote
> >> innews:go0pr0$6jj$1@ai
> > oe.org:
>
> >> > "Allan Herriman" <allanherri...@hotmail.com> wrote in message
> >> >news:Xns9BBCD0C44FABBallanherrimanhotmail@216.151.153.43...
> >> >> Hi,
>
> >> >> I guess my questions are:
>
> >> >> 2.  Will future generations FPGAs be able to be programmed via
> >> >> PCIe? If so, when?
>
> >> > Now? ;) Just need to use some external  components to tie it
> >> > together...or use partial reconfiguration (PR) flow.
>
> >> I meant "gluelessly".  With PR, one must get the original
> >> configuration into the FPGA somehow, and (as I understand it) that
> >> cannot be done with PCIe.
>
> >> Thanks for your comments.
>
> >> Allan
>
> > I haven't looked at processors like the Atom in a while, but I seem to
> > recall that you get some number of general purpose I/O pins on most
> > any processor.  You only need four pins to completely control an FPGA
> > configuration; PRGM, CCLK, DONE, INIT.  They can be bit banged in
> > software.  The FPGA interface is not used very much when considered in
> > the grand scheme of things.  So I expect you will never see direct
> > support for it on processors.
>
> > I also doubt that you will see dedicated support for PCIe in FPGAs.
> > This is a bit lofty for a configuration interface.  PCIe is point to
> > point (right?) and taking one of the two PCIe interfaces on an Atom
> > for booting the FPGA would be a bit of overkill.  There are few
> > applications where a processor like the Atom is used and you can't
> > wait the few milliseconds for the FPGA to boot serially.
>
> That PCIe isn't wasted; it is needed for FPGA <-> cpu comms after
> configuration.

In your case that may be useful.  My point is that in the general case
this is not something that would be widely useful since PCIe ports are
a very "expensive" way to configure a part when all you really need is
four GPIO pins on the host.


> I was actually thinking of applications without the chance of using GPIO
> lines, e.g. on a PCIe plugin card.

I don't know PCIe much, but I have worked with PCI before and I don't
think it is practical to use an FPGA to provide the PCI interface.
This issue may have been resolved at some point, but I want to say
that an FPGA does not boot fast enough to respond to the initial
enumeration comms on the bus.  Has this issue been addressed so that
an FPGA can boot from an on board PROM and provide a PCIe interface?


> It still seems that the PCIe to local bus bridge is the best solution for
> my hypothetical problem.  The other suggestions involved Flash memories
> (with an implied extra step during manufacturing to program the dang
> things, not to mention the extra complexity involved with in-the-field
> upgrades of that image) or a non-trivial amount of glue logic.

I think the idea is that the image required to boot the FPGA enough to
make it bootable over the PCIe interface would be pretty stable.  So
the concerns of needing to fix that would be a bit overblown.  In
fact, it is likely that you could design the interface to the boot
Flash so that it can be programmed over the PCIe bus.  Then, as long
as the reprogramming did not go bust in the middle, you could update
the Flash just like you load the rest of the image.

Of course, the local bus interface still requires some extra logic to
boot the FPGA, no?  Or does the bridge chip provide signals that can
be used directly?


> I thought Glen's suggestion of loading the image into SRAM first was
> neat, but probably not suitable for me.

You don't really need to load the FPGA fresh on **every** boot do
you?  You could provide the Flash to boot from and only update it when
you have changes.  You could use a protected boot block to load the
initial image.  If an update is installed in the rest of the Flash,
the initial image would then reboot the FPGA from that updated image.
This gives you a guaranteed level of boot so that you never loose the
ability to boot and can still support updates.  The selection of
whether to reboot from the secondary image could be put under software
control.

I've been working with a flash based FPGA which uses the Flash as a
shadow of the configuration RAM.  The part can be booted from the
Flash or the RAM can be directly configured without disturbing the
Flash for temporary boots.  I think this provides some interesting
boot and update possibilities when controlled by a host.

Rick

Article: 138508
Subject: Re: Where can a cheap programmer for Xilinx Virtex II XC2V1500 be
From: Weng Tianxiang <wtxwtx@gmail.com>
Date: Wed, 25 Feb 2009 10:15:55 -0800 (PST)
Links: << >>  << T >>  << A >>
On Feb 23, 4:49=A0pm, Weng Tianxiang <wtx...@gmail.com> wrote:
> On Feb 23, 12:42=A0pm, Dave Pollum <vze24...@verizon.net> wrote:
>
>
>
>
>
> > On Feb 23, 3:38=A0pm, Weng Tianxiang <wtx...@gmail.com> wrote:
>
> > > Hi,
> > > It is intersting to find that $24.50 is for an Altera ByteBlast
> > > programmer mentioned in a topics in FPGA group.
>
> > > I need to buy a programmer suitable for Xilinx Virtex II XC2V1500 chi=
p
> > > only.
>
> > > Please give any tips where I can buy a cheap programmer.
>
> > > Thank you.
>
> > > Weng
>
> > Digilent (digilentinc.com) has inexpensive programming cables.
> > -Dave Pollum
>
> Hi Dave,
> Good information! I need cables too. But hopefully I may get a set of
> programmer plus its cables from one person or a company.
>
> Weng- Hide quoted text -
>
> - Show quoted text -

Hi Dave,
I checked Digilent.com website and I am not sure which one works for
my system: Xilinx Virtext II XC2V 1000.

JTAG Programming Cable $12.00
low-cost JTAG configuration solution
for use with any JTAG-programmable device
connects directly to the parallel port of a PC, and to a standard 6-
pin JTAG programming header
can program devices that have a JTAG voltage of 1.8V or greater

I found my board has a 14-pin connector, but above specs says it has a
6-pin JTAG programming header. Is it fit?

Is Xilinx iMPACT software still usable?

Please give me a help to determine if which is fit.

Thank you.

Weng


Article: 138509
Subject: Re: Can Xilinx IST automatically detect non-compatible library?
From: Weng Tianxiang <wtxwtx@gmail.com>
Date: Wed, 25 Feb 2009 10:53:29 -0800 (PST)
Links: << >>  << T >>  << A >>
On Feb 25, 9:30=A0am, LittleAlex <alex.lo...@email.com> wrote:
> On Feb 25, 9:05 am, Weng Tianxiang <wtx...@gmail.com> wrote:
>
>
>
>
>
> > Hi,
> > When I was generating my code, I didn't know what exact Xilinx chip
> > may be used so that I selected Virtex V chip as my target one time.
> > During the development, I might have tried to generate libraries with
> > Virtex II chips because I have many Virtex II libraries ready to use.
> > It led to the situation that I really don't know which library belongs
> > to which chip. For simulations, it doesn't matter. But now I am trying
> > to implement my design on Virtex II chip, the problem comes clear: if
> > all libraries used in my simulation are for Virtex II? I can't answer
> > the question.
>
> > So I would like to ask if Xilinx IST can automatically detect an error
> > when a Virtex V chip library is used for a Virtex II chip project. I
> > think it is. But to reduce risks of errors, I would like to ask
> > experienced persons for a positive answer without any guess.
>
> > Thank you.
>
> > Weng
>
> Simulation libraries and Synthesis libraries are different.
>
> XST does check synthesis libraries. =A0PAR will fail if the wrong
> libraries are linked.
>
> AL- Hide quoted text -
>
> - Show quoted text -

Hi Al,
Can I have a text editor software to find which type of chips a
library belongs to?

So that I don't have to wait for PAR error to happen.

I remember *.edn files are libraried for synthesis. But I couldn't
find any keyword about the chip in a *.edn file.

Weng

Article: 138510
Subject: Re: Fm digital baseband demodulation
From: My Name <myemail@a_domain.com>
Date: Wed, 25 Feb 2009 11:45:44 -0800
Links: << >>  << T >>  << A >>

In the general case, I and Q aren't normalized and cover a certain
amplitude range. Some kind of normalization, e. g. dividing by I^2+Q^2,
is required, if the decoder output has to be correctly scaled. Cause the
carrier magnitude can be expected to vary only slowly, other means as an
AGC can be used as well. This is the case with usual FM receivers.Has
anyone  an idea about implementation of an AGC for fm demodulator?


-- 
xristos
------------------------------------------------------------------------
xristos's Profile: http://www.fpgacentral.com/group/member.php?userid=15
View this thread: http://www.fpgacentral.com/group/showthread.php?t=88112


Article: 138511
Subject: Re: Configure FPGA via PCIe
From: hal-usenet@ip-64-139-1-69.sjc.megapath.net (Hal Murray)
Date: Wed, 25 Feb 2009 14:10:09 -0600
Links: << >>  << T >>  << A >>

>That PCIe isn't wasted; it is needed for FPGA <-> cpu comms after 
>configuration.

>I was actually thinking of applications without the chance of using GPIO 
>lines, e.g. on a PCIe plugin card.

This problem has been around for a long time.  It also happens
with PCI (no e).

The fundamental problem is that you need a place to stand while
you are programming the FPGA so it's tricky to get the FPGA to
program itself before it has been programmed.

In order to program a FPGA from a CPU, you need something like
GPIO pins.  Most modern compute CPUs (as compared to embedded CPUs)
don't have any "extra" pins like that.

The best approach I know of is to load the FPGA from the normal
serial PROM and setup a few extra pins on the FPGA so that it can
reprogram the PROM.  It may require some glue.

As long as you don't shoot yourself in the foot you can do that
over and over.  You probably die if you lose power in the middle
of re-programming.


I forget the vendor name, but somebody makes a set of PCI to xxx
chips.  They are often used to talk to FPGAs.  They have a bus
to transfer large clumps of data, and also several GPIO pins.
I expect they do/will make a PCIe version.

If that fits with your design, you could use one of them
between your FPGA and the PCIe bus.  You could wire up a few
of the GPIO pins to program the FPGA.

This is ugly in the sense that it requires another big expensive
chip, but it might let you use a smaller FPGA since the bus
interface can be simpler.


-- 
These are my opinions, not necessarily my employer's.  I hate spam.


Article: 138512
Subject: Re: mb-gcc producing incorrect code ???
From: hal-usenet@ip-64-139-1-69.sjc.megapath.net (Hal Murray)
Date: Wed, 25 Feb 2009 14:24:28 -0600
Links: << >>  << T >>  << A >>
>I guess the bigger question here is how to correctly
>interface a little endian peripheral to a big-endian
>SoC ?

It's a hard problem.  It's been around for ages.


>Byte swapping everything would mean that the user manual
>for the pripoheral would have to be rewritten as well ...

You may want byte swapping in the hardware.  It depends
on what you are talking to.  If it's something like a disk
or ethernet, where you often transfer text, you are probably
better off treating it as a byte stream which means you will
have to byte-swap (in software) to use things like 4 byte
integers.

Note that if you byte-swap the bus pins, that will
byte swap addresses on a shared bus.  So you may have
to swap addresses in the driver so they will come out
right when the hardware swaps them again.


You can probably write a user manual that covers both
cases.  The trick is to write it using words and word
addresses/offsets, then describe each word with
pictures and bit offsets or terms like "high byte"
rather than byte addresses.  "Word" in that sentence
means whatever the natural width of the bus is.

Or you can just describe it for the normal/natural case
and let the poor guy who is using it on the wrong-endian
system sort things out.  He should be familiar with the
problem and know how to read wrong-endian data sheets.

-- 
These are my opinions, not necessarily my employer's.  I hate spam.


Article: 138513
Subject: Converting state machine encoding to std_logic_vector
From: "M. Hamed" <mhelshou@hotmail.com>
Date: Wed, 25 Feb 2009 12:51:26 -0800 (PST)
Links: << >>  << T >>  << A >>
Is there a way in VHDL to access the FSM encoding by the synthesis
tool as a std_logic_vector.

in other words: is there a tool supported way to convert my enumerated
state variable (eg: INIT, CLK_LOW, CLK_HIGH, etc) to a
std_logic_vector?

The only alternative I'm seeing is having my own process in the
format:

process(state)
begin
   case state is
      when INIT =>
         out <= "000";
     when CLK_LOW =>
         out <= "001";
     .
     .
     .
   end case;
end process;

Thanks!

Article: 138514
Subject: Re: Converting state machine encoding to std_logic_vector
From: Frank Buss <fb@frank-buss.de>
Date: Wed, 25 Feb 2009 22:15:00 +0100
Links: << >>  << T >>  << A >>
M. Hamed wrote:

> Is there a way in VHDL to access the FSM encoding by the synthesis
> tool as a std_logic_vector.
> 
> in other words: is there a tool supported way to convert my enumerated
> state variable (eg: INIT, CLK_LOW, CLK_HIGH, etc) to a
> std_logic_vector?
> 
> The only alternative I'm seeing is having my own process in the
> format:
> 
> process(state)
> begin
>    case state is
>       when INIT =>
>          out <= "000";
>      when CLK_LOW =>
>          out <= "001";
>      .
>      .
>      .
>    end case;
> end process;

I don't think there is a portable way to access the std_logic_vector of a
state machine, because a synthesizer is not required to synthesize it as a
bit vector at all. They can optimize it away, using gray codes etc.

Why do you need to translate your state to a number?

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

Article: 138515
Subject: Re: Converting state machine encoding to std_logic_vector
From: mhelshou@hotmail.com
Date: Wed, 25 Feb 2009 13:46:48 -0800 (PST)
Links: << >>  << T >>  << A >>
For debugging purposes. My FSM gets stuck somewhere and I wanted to be
able to read the current state as a register.

On Feb 25, 2:15=A0pm, Frank Buss <f...@frank-buss.de> wrote:
> M. Hamed wrote:
> > Is there a way in VHDL to access the FSM encoding by the synthesis
> > tool as a std_logic_vector.
>
> > in other words: is there a tool supported way to convert my enumerated
> > state variable (eg: INIT, CLK_LOW, CLK_HIGH, etc) to a
> > std_logic_vector?
>
> > The only alternative I'm seeing is having my own process in the
> > format:
>
> > process(state)
> > begin
> > =A0 =A0case state is
> > =A0 =A0 =A0 when INIT =3D>
> > =A0 =A0 =A0 =A0 =A0out <=3D "000";
> > =A0 =A0 =A0when CLK_LOW =3D>
> > =A0 =A0 =A0 =A0 =A0out <=3D "001";
> > =A0 =A0 =A0.
> > =A0 =A0 =A0.
> > =A0 =A0 =A0.
> > =A0 =A0end case;
> > end process;
>
> I don't think there is a portable way to access the std_logic_vector of a
> state machine, because a synthesizer is not required to synthesize it as =
a
> bit vector at all. They can optimize it away, using gray codes etc.
>
> Why do you need to translate your state to a number?
>
> --
> Frank Buss, f...@frank-buss.dehttp://www.frank-buss.de,http://www.it4-sys=
tems.de


Article: 138516
Subject: Re: virtex 5 columns
From: gabor <gabor@alacron.com>
Date: Wed, 25 Feb 2009 14:14:29 -0800 (PST)
Links: << >>  << T >>  << A >>
On Feb 25, 9:51=A0am, colin <colin_toog...@yahoo.com> wrote:
> Hello
>
> I have a new virtex 5 design with a lot of IO going at the same speed.
> I've been told to put all this IO on the same column. Also I can then
> use the DCI bank cascading.
>
> Does anyone know the logic behind the bank numbering? I can't find any
> data on which banks are in which column.
>
> Colin

You really need to dig for this information.  I was told to use
"ADEPT" to get a picture of the columns.  There is a long
thread on the Xilinx forums about this.

http://forums.xilinx.com/xlnx/board/message?board.id=3DVirtex&thread.id=3D9=
1&view=3Dby_date_ascending&page=3D1

Regards,
Gabor

Article: 138517
Subject: Re: Converting state machine encoding to std_logic_vector
From: Frank Buss <fb@frank-buss.de>
Date: Wed, 25 Feb 2009 23:28:02 +0100
Links: << >>  << T >>  << A >>
mhelshou@hotmail.com wrote:

> For debugging purposes. My FSM gets stuck somewhere and I wanted to be
> able to read the current state as a register.

So you have some real hardware and maybe an embedded CPU, which can read
the state? Did you try to write a testbench in a simulator? The integrated
simulator in Quartus is crap, but the free ModelSim version for Quartus is
nice and you can see it in a timing diagram, with the names of the states
instead of numbers, setting breakpoints etc. The integrated simulator in
Xilinx ISE is usable, too.

First you should reproduce the problem with a testbench, because this helps
later for regression testing, if you change your entity. For your
statemachine problem: Once I had a similar problem: The statemachine justs
stops on real hardware from time to time, but it was impossible from the
VHDL code. The bug was, that I didn't latched the (asynchronous) input
signals.

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

Article: 138518
Subject: Re: Fm digital baseband demodulation
From: doug <xx@xx.com>
Date: Wed, 25 Feb 2009 14:38:17 -0800
Links: << >>  << T >>  << A >>


My Name wrote:

> In the general case, I and Q aren't normalized and cover a certain
> amplitude range. Some kind of normalization, e. g. dividing by I^2+Q^2,
> is required, if the decoder output has to be correctly scaled. Cause the
> carrier magnitude can be expected to vary only slowly, other means as an
> AGC can be used as well. This is the case with usual FM receivers.Has
> anyone  an idea about implementation of an AGC for fm demodulator?
> 
> 
You do not need it. You are measuring angles not amplitude.

Article: 138519
Subject: Re: Configure FPGA via PCIe
From: Allan Herriman <allanherriman@hotmail.com>
Date: 25 Feb 2009 23:18:01 GMT
Links: << >>  << T >>  << A >>
rickman <gnuarm@gmail.com> wrote in
news:9e5e3729-4da1-41b4-9ec2-9c8f5dfe24d6@r36g2000vbp.googlegroups.com: 

> On Feb 25, 4:49 am, Allan Herriman <allanherri...@hotmail.com> wrote:
>> rickman <gnu...@gmail.com> wrote
>> innews:3774b465-11f4-4daa-aee7-d44f72fce9a6@n20g2000vba.googlegroups.c
>> om: 
>>
>>
>>
>> > On Feb 24, 8:27 am, Allan Herriman <allanherri...@hotmail.com>
>> > wrote: 
>> >> "Krzysztof Kepa" <nospam_blond...@poczta.fm> wrote
>> >> innews:go0pr0$6jj$1@ai
>> > oe.org:
>>
>> >> > "Allan Herriman" <allanherri...@hotmail.com> wrote in message
>> >> >news:Xns9BBCD0C44FABBallanherrimanhotmail@216.151.153.43...
>> >> >> Hi,
>>
>> >> >> I guess my questions are:
>>
>> >> >> 2.  Will future generations FPGAs be able to be programmed via
>> >> >> PCIe? If so, when?
>>
>> >> > Now? ;) Just need to use some external  components to tie it
>> >> > together...or use partial reconfiguration (PR) flow.
>>
>> >> I meant "gluelessly".  With PR, one must get the original
>> >> configuration into the FPGA somehow, and (as I understand it) that
>> >> cannot be done with PCIe.
>>
>> >> Thanks for your comments.
>>
>> >> Allan
>>
>> > I haven't looked at processors like the Atom in a while, but I seem
>> > to recall that you get some number of general purpose I/O pins on
>> > most any processor.  You only need four pins to completely control
>> > an FPGA configuration; PRGM, CCLK, DONE, INIT.  They can be bit
>> > banged in software.  The FPGA interface is not used very much when
>> > considered in the grand scheme of things.  So I expect you will
>> > never see direct support for it on processors.
>>
>> > I also doubt that you will see dedicated support for PCIe in FPGAs.
>> > This is a bit lofty for a configuration interface.  PCIe is point
>> > to point (right?) and taking one of the two PCIe interfaces on an
>> > Atom for booting the FPGA would be a bit of overkill.  There are
>> > few applications where a processor like the Atom is used and you
>> > can't wait the few milliseconds for the FPGA to boot serially.
>>
>> That PCIe isn't wasted; it is needed for FPGA <-> cpu comms after
>> configuration.
> 
> In your case that may be useful.  My point is that in the general case
> this is not something that would be widely useful since PCIe ports are
> a very "expensive" way to configure a part when all you really need is
> four GPIO pins on the host.
> 
> 
>> I was actually thinking of applications without the chance of using
>> GPIO lines, e.g. on a PCIe plugin card.
> 
> I don't know PCIe much, but I have worked with PCI before and I don't
> think it is practical to use an FPGA to provide the PCI interface.
> This issue may have been resolved at some point, but I want to say
> that an FPGA does not boot fast enough to respond to the initial
> enumeration comms on the bus.  Has this issue been addressed so that
> an FPGA can boot from an on board PROM and provide a PCIe interface?
> 
> 
>> It still seems that the PCIe to local bus bridge is the best solution
>> for my hypothetical problem.  The other suggestions involved Flash
>> memories (with an implied extra step during manufacturing to program
>> the dang things, not to mention the extra complexity involved with
>> in-the-field upgrades of that image) or a non-trivial amount of glue
>> logic. 
> 
> I think the idea is that the image required to boot the FPGA enough to
> make it bootable over the PCIe interface would be pretty stable.  So
> the concerns of needing to fix that would be a bit overblown.  In
> fact, it is likely that you could design the interface to the boot
> Flash so that it can be programmed over the PCIe bus.  Then, as long
> as the reprogramming did not go bust in the middle, you could update
> the Flash just like you load the rest of the image.
> 
> Of course, the local bus interface still requires some extra logic to
> boot the FPGA, no?  Or does the bridge chip provide signals that can
> be used directly?


They usually have a few GPIO lines as well as a parallel data bus.  This 
allows some sort of slave parallel mode to be used without glue logic.

Just in case you are interested, here are some typical parts:

1 Lane:
http://www.plxtech.com/products/expresslane/pex8311.asp

4 Lanes with dedicated FPGA loading support:
http://www.gennum.com/video/products/gn4124

Here's the article that inspired this thread:
http://www.pldesignline.com/howto/210300269

Regards,
Allan

Article: 138520
Subject: Re: Configure FPGA via PCIe
From: Allan Herriman <allanherriman@hotmail.com>
Date: 25 Feb 2009 23:26:12 GMT
Links: << >>  << T >>  << A >>
hal-usenet@ip-64-139-1-69.sjc.megapath.net (Hal Murray) wrote in 
news:ddadncju0b08ODjUnZ2dnUVZ_qvinZ2d@megapath.net:

> I forget the vendor name, but somebody makes a set of PCI to xxx
> chips.  They are often used to talk to FPGAs.  They have a bus
> to transfer large clumps of data, and also several GPIO pins.
> I expect they do/will make a PCIe version.
> 
> If that fits with your design, you could use one of them
> between your FPGA and the PCIe bus.  You could wire up a few
> of the GPIO pins to program the FPGA.
> 
> This is ugly in the sense that it requires another big expensive
> chip, but it might let you use a smaller FPGA since the bus
> interface can be simpler.


We've come full circle; what you wrote is what I was suggesting in my 
original post :)

Here's what I said:

"So far, it seems the best way is (despite the FPGA on-board 
transceivers) to use a PCIe to local bus bridge chip from PLX or Gennum."

They're not so big an expensive compared with the other solutions I've 
been considering.  The silicon costs a few dollars more, but I can 
eliminate the manufacturing step for programming a Flash.

Regards,
Allan

Article: 138521
Subject: Re: Very fast counter in VirtexII
From: -jg <Jim.Granville@gmail.com>
Date: Wed, 25 Feb 2009 16:08:00 -0800 (PST)
Links: << >>  << T >>  << A >>
> Thanks for the useful tips; it seems the primary approach is to "stretch"
> the signals of interest into fast elements like shift registers and/or carry
> chains, and then count these up at some leisure later (how?). That sounds
> like it takes a lot of resources (e.g., 16 ticks per slice if I use a
> SRL16E). This could explain why some of the papers I've glanced at seem to
> take pretty much an entire chip to make a couple of these high-end delay
> measuring devices.

The highest precision ones capture a delay line, and then decode the
edge position later, to decide how many delay elements were used.
Of course, this also needs a calibrate action, so one method is to
interleave two
delay lines, one is doing a CAL whilst the other measures - you can
use
a lot of elements doing this, but they are cheap in a fpga.


> For now, since it seems feasible to run a small (8 bit)
> counter at 204.8 MHz, I'll try that route. 4.883 ns of precision is about
> 1.5 meters when you multiply by c, so that's still useful to me. Once I get
> the basic structure figured out I can look at speeding it up. Today I got
> the input logic figured out (what signal is my start condition, and what is
> my stop). Since I'm using these signals to calibrate out differences between
> identical bitstreams on separated boards inside a common chassis, the
> differential delays inside the logic should mostly wash out.

Don't forget most FPGAs allow multiple phase clocks, so you can
duplicate this 4 x on 4 phases, and compare the 4 answers

-jg


Article: 138522
Subject: Re: Configure FPGA via PCIe
From: Brian Drummond <brian_drummond@btconnect.com>
Date: Thu, 26 Feb 2009 00:09:37 +0000
Links: << >>  << T >>  << A >>
On Wed, 25 Feb 2009 10:05:04 -0800 (PST), rickman <gnuarm@gmail.com> wrote:

>On Feb 25, 4:49 am, Allan Herriman <allanherri...@hotmail.com> wrote:
>> rickman <gnu...@gmail.com> wrote innews:3774b465-11f4-4daa-aee7-d44f72fce9a6@n20g2000vba.googlegroups.com:

>
>I don't know PCIe much, but I have worked with PCI before and I don't
>think it is practical to use an FPGA to provide the PCI interface.
>This issue may have been resolved at some point, but I want to say
>that an FPGA does not boot fast enough to respond to the initial
>enumeration comms on the bus.  Has this issue been addressed so that
>an FPGA can boot from an on board PROM and provide a PCIe interface?

Since PCI (at least in CompactPCI form) and PCIe theoretically support
hotplugging, I don't see that this is a fundamental issue; it must be possible
to rescan the PCI bus to detect and add devices that weren't awake (or even
plugged in!) at boot time.

Certainly on Linux there is a PCI Hotplug interface; I don't know how (or even
if) it works in this role. But it suggests that the problem must have a
solution.

- Brian

Article: 138523
Subject: Re: Converting state machine encoding to std_logic_vector
From: Dave <dhschetz@gmail.com>
Date: Wed, 25 Feb 2009 16:31:37 -0800 (PST)
Links: << >>  << T >>  << A >>
On Feb 25, 3:51=A0pm, "M. Hamed" <mhels...@hotmail.com> wrote:
> Is there a way in VHDL to access the FSM encoding by the synthesis
> tool as a std_logic_vector.
>
> in other words: is there a tool supported way to convert my enumerated
> state variable (eg: INIT, CLK_LOW, CLK_HIGH, etc) to a
> std_logic_vector?
>
> The only alternative I'm seeing is having my own process in the
> format:
>
> process(state)
> begin
> =A0 =A0case state is
> =A0 =A0 =A0 when INIT =3D>
> =A0 =A0 =A0 =A0 =A0out <=3D "000";
> =A0 =A0 =A0when CLK_LOW =3D>
> =A0 =A0 =A0 =A0 =A0out <=3D "001";
> =A0 =A0 =A0.
> =A0 =A0 =A0.
> =A0 =A0 =A0.
> =A0 =A0end case;
> end process;
>
> Thanks!

Try this - it isn't guaranteed to be the same encoding as the
synthesizer will use, but it will give you the state represented by a
SLV:

library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;

type state_type is (IDLE, STATE1, STATE2, ...);
signal state : state_type;
signal state_slv : std_logic_vector(num_bits-1 downto 0);

...

state_slv <=3D std_logic_vector(to_unsigned(state_type'pos(state),
num_bits));

This should give you the state number, starting from zero and in the
same order as they are declared the the type definition.

Dave


Article: 138524
Subject: Re: Converting state machine encoding to std_logic_vector
From: "KJ" <kkjennings@sbcglobal.net>
Date: Wed, 25 Feb 2009 21:53:21 -0500
Links: << >>  << T >>  << A >>

> <mhelshou@hotmail.com> wrote in message 
> news:3a9d2206-c1a6-420d-a9d6-6e6cb8b610e8@v15g2000yqn.googlegroups.com...
> For debugging purposes. My FSM gets stuck somewhere and I wanted to be
> able to read the current state as a register.

Presumably the debug you're referring to is in hardware, not simulation 
since sim wouldn't require converting an enumerated type into a 
std_logic_vector for debug.  That being the case, then you could peruse your 
synthesis log file it likely says how it is encoding the enumerated signal, 
there is likely a note to that effect.  More to the point though, you'll 
need to bring that signal out to I/O pins so you'll need to be using 
whatever sort of 'signal probe' stuff that your tools support which means 
you'll be navigating down to the entity in question and then pulling out the 
synthesized signals.

The other way to look at it, is that if you're certain that the FSM is 
'stuck somewhere' and not something entirely unrelated then this likely 
implies that you have either an input to the state machine that is not 
synchronized to the clock, or simply that you're running the thing faster 
than you should be as defined by the timing analysis report.  Usually a 
quick perusal checking the logic path of the inputs will turn up the source 
of unsynchronized input signals and an even quicker perusal of the timing 
report will uncover if you're trying to clock the design at too high of a 
clock rate.

Kevin Jennings 





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