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 148300

Article: 148300
Subject: Re: Q: Standard Programming Idiom
From: Frank Buss <fb@frank-buss.de>
Date: Tue, 6 Jul 2010 07:14:59 +0200
Links: << >>  << T >>  << A >>
Richard wrote:

> I just came across a - what I think - must be a quite standard 
> programming idiom for implementing an FSM. Essentially, I read
> a byte value byte_in sequentially, and assign it to the appropriate
> portions of signal register. As you can see, the read_en signal
> must be HIGH in the state before the data in byte_in can be read.
> Unfortunately, my FSM looks messy and I wonder if I could compress
> the states a bit.

I would use a counter and shifting:

    signal counter: natural range 0 to 4 := 0;

    process(clk)
    begin
        if rising_edge(clk) then
		case state is
			when start =>
				read_en <= '1';
				counter <= 4;
				state <= readByte;
			when readByte =>
				if counter > 0 then
					register <= byte_in & register(31 downto 8);
					counter <= counter - 1;
				else
					read_en <= '0';
					state <= start;
				end if;
		end case;
        end if;
    end process;

If you don't do other things in your state machine, you even don't need a
state machine, just the counter, but this can lead to difficult to maintain
code, if you later want to add features.

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

Article: 148301
Subject: Re: Q: Standard Programming Idiom
From: backhus <goouse99@googlemail.com>
Date: Tue, 6 Jul 2010 00:06:08 -0700 (PDT)
Links: << >>  << T >>  << A >>
On 6 Jul., 01:18, Richard <Richar...@hotmail.com> wrote:
> Hi all,
>
> I just came across a - what I think - must be a quite standard
> programming idiom for implementing an FSM. Essentially, I read
> a byte value byte_in sequentially, and assign it to the appropriate
> portions of signal register. As you can see, the read_en signal
> must be HIGH in the state before the data in byte_in can be read.
> Unfortunately, my FSM looks messy and I wonder if I could compress
> the states a bit.
>
> signal read_en =A0 =A0 =A0 =A0 =A0 : std_logic;
> signal byte_in =A0 =A0 =A0 =A0 =A0 : std_logic_vector(7 downto 0);
> signal register =A0 =A0 =A0 =A0 =A0: std_logic_vector(31 downto 0);
>
> process (clk, reset)
> =A0 =A0 begin
> =A0 =A0 =A0 =A0 =A0if (clk'event and clk =3D '1') then
> =A0 =A0 =A0 =A0 =A0 =A0case state is
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 when READ0 =3D>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 read_en <=3D 1;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 state =3D READ1;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 when READ1 =3D>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 read_en <=3D 1;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 register(7 downto 0) <=3D byte_in;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 state =3D READ2;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 when READ2 =3D>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 read_en <=3D 1;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 register(15 downto 8) <=3D byte_in;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 state =3D READ3;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 when READ3 =3D>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 read_en <=3D 1;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 register(23 downto 16) <=3D byte_in;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 state =3D READ4;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 when READ4 =3D>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 register(31 downto 24) <=3D byte_in;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 state =3D DONE;
> =A0 =A0 =A0 =A0 =A0 =A0end case;
> end process;
>
> Many thanks for your comments,
> Rich

Hi Rich,
first, you have missed to implement the reset branch to set the
initial state at Pon.
The reset signal is in your sensitivity list already.
Then, you have no default assignments for read_en and register(n+7
downto n), so read_en will always be active.
Yo set it in the first state, without assigning the data in value
(probably to couteract pipelining effects), but you are not
deactivating in the last read,
And also, once you reached DONE happens ...what?
That state is not covered.
Besides, you wrote just state =3D something, which is no legal
assignment. It's either :=3D or <=3D .

For a cleaner implementation you may implement the state as a variable
and define the type in the process too.

signal read_en           : std_logic;
signal byte_in           : std_logic_vector(7 downto 0);
signal register          : std_logic_vector(31 downto 0);

process (clk, reset)
  type state_type : (READ0, READ1,READ2,READ3,DONE);
  variable state : state_type;
    begin
         if reset =3D '1' then
               state :=3D READ0;
               read_en <=3D '0';
               register <=3D  (otheres =3D> '0');
         elsif rising_edge(clk) then
           -- calculate branches
           case state is
                when READ0 =3D>   state :=3D READ1;
                when READ1 =3D>   state :=3D READ2;
                when READ2 =3D>   state :=3D READ3;
                when READ3 =3D>   state :=3D READ4;
                when READ4 =3D>   state :=3D DONE;
                when DONE  =3D>    state :=3D READ0;
           end case;
           -- set outputs here
            read_en <=3D '0';  -- default output assignment
           case state is
                when READ0 =3D>  null;
                when READ1 =3D>  read_en <=3D 1;
                                           register(7 downto 0 <=3D
byte_in;
                when READ2 =3D>  read_en <=3D 1;
                                           register(15 downto 8) <=3D
byte_in;
                when READ3 =3D>  read_en <=3D 1;
                                           register(23 downto 16) <=3D
byte_in;
                when READ4 =3D>  read_en <=3D 1;
                                           register(31 downto 24) <=3D
byte_in;
                when DONE  =3D>   null;
           end case;
end process;

Here the state valu changes imediately after an active cloch edge and
the outputs are sett according to the new states.
If the condition still applies that the read enable has to be set one
state before the assignment of the data_in value, you can easily
rearrange the output assignments.
Keep in mind that the reset conditions must met the output values for
the initial state.

You may also decide to use '1' as the default value for read_en. then
you have just to cover the few cases where read_en =3D '0'. Saves some
code lines.

See what works for you.

Have a nice synthesis
  Eilert

Article: 148302
Subject: Re: DMA operation to 64-bits PC platform
From: Frank van Eijkelenburg <fei.technolution@gmail.com>
Date: Tue, 6 Jul 2010 02:00:09 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Jul 2, 9:04=A0pm, Charles Gardiner <charles.gardi...@invalid.invalid>
wrote:
> Hi Frank,
>
>
>
> > I am not sure if we understand each other.
>
> Yes, it certainly sounds like that.
>
> > What do you mean by
> > completing the request with IoCompleteRequest? There is no request
> > from software point of view.
>
> I think this might clear up the reason why your data is missing. (See als=
o below
> about the type of DMA). I don't think the S/G list you are getting is des=
cribing
> your application buffer. This is best done by specifying DO_DIRECT_IO as =
the DMA
> method for your device. If you specify DO_BUFFERED_IO you will get an S/G=
 List
> describing an intermediate buffer in kernel space and this probably never=
 gets
> copied over to your application space buffer unless you terminate the req=
uest.
> I've never done the 'neither' method myself and from what I hear, it's a
> complicated beast.
>
> > The FPGA will do a DMA write (data from
> > FPGA to PC memory) at its own initiative. The allocated memory is used
> > as long as the software is running. I do not allocate new memory for
> > each new DMA transfer, but at startup a large piece of memory is
> > allocated and the physical addresses are written to the FPGA by the
> > driver software.
>
> Sounds like you are doing something like a circular buffer in memory whic=
h stays
> alive as long as your device does?
>
>
>
> > And yes, we use a DMA adapter in combination with the
> > GetScatterGatherList method. We already used this in another project
> > but that was PCI and DMA read (data from PC memory to FPGA).
>
> > By the way, where can I set the type of DMA?
>
> Typically, you set the DMA buffering method in your AddDevice function af=
ter you
> create your device object. Quoting from Oney's book,
>
> NTSTATUS AddDevice(..) {
> =A0 =A0PDEVICE_OBJECT =A0 =A0fdo;
>
> =A0 =A0IoCreateDevice(....., &fdo);
> =A0 =A0fdo->Flags |=3D DO_BUFFERED_IO;
> =A0 =A0 =A0 =A0 =A0 =A0 <or>
> =A0 =A0fdo->Flags |=3D DO_DIRECT_IO;
> =A0 =A0 =A0 =A0 =A0 =A0 <or>
> =A0 =A0fdo->Flags |=3D 0; =A0// i.e. neither Direct nor Buffered
>
> And, you can't change your mind afterwards.
>
> By the way if my assumption about the circular buffer in your design is c=
orrect,
> there is a slightly more standard solution (standard in the sense that ev=
erybody
> on the microsoft drivers newgroup seems to do it). It however requires tw=
o threads
> in your application. The first one requests a buffer (using new or malloc=
) and
> sets up an I/O Request ReadFile, WriteFile or DeviceIoControl referencing=
 this
> buffer. This is performed as an asynchronous request.
>
> The driver recognises this request and pends it indefinitely, (typically =
terminate
> it when your driver is shutting down, otherwise windows will probably han=
g).
> Pending the request has the nice side effect that the buffer now becomes =
locked
> down permanently.
>
> Assuming you have set up your driver to use DO_DIRECT_IO DMA, you can get=
 the S/G
> list describing the application space buffer as you are currently doing a=
nd feed
> this to your FPGA.
>
> Using the second thread in your application you can constantly read data =
from the
> locked down pages (you app. space buffer) that are being written by your =
FPGA.
>
> Assuming the DO_DIRECT_IO solves your problem (I think there is a good ch=
ance), I
> would however still consider migrating to a KMDF based driver, particular=
ily if
> you are writing a new one. It's much easier to maintain and is probably m=
ore
> portable for future MS versions.
>
>
>
> > best regards,
>
> > Frank
>
> best regards,
> Charles

Hi Charles,

We tried your suggestion (we were using BUFFERED_IO). Unfortunately it
was not the (final) solution. Perhaps there are more causes for the
problem. Anyway, thanks for your suggestion. We are almost out of
ideas of what we can test. Do you have other ideas or tests we can do
to find the cause? I hope to fix the problem before my vacation (only
one day left :)

best regards,

Frank

Article: 148303
Subject: Re: DMA operation to 64-bits PC platform
From: Frank van Eijkelenburg <fei.technolution@gmail.com>
Date: Tue, 6 Jul 2010 02:00:16 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Jul 2, 9:04=A0pm, Charles Gardiner <charles.gardi...@invalid.invalid>
wrote:
> Hi Frank,
>
>
>
> > I am not sure if we understand each other.
>
> Yes, it certainly sounds like that.
>
> > What do you mean by
> > completing the request with IoCompleteRequest? There is no request
> > from software point of view.
>
> I think this might clear up the reason why your data is missing. (See als=
o below
> about the type of DMA). I don't think the S/G list you are getting is des=
cribing
> your application buffer. This is best done by specifying DO_DIRECT_IO as =
the DMA
> method for your device. If you specify DO_BUFFERED_IO you will get an S/G=
 List
> describing an intermediate buffer in kernel space and this probably never=
 gets
> copied over to your application space buffer unless you terminate the req=
uest.
> I've never done the 'neither' method myself and from what I hear, it's a
> complicated beast.
>
> > The FPGA will do a DMA write (data from
> > FPGA to PC memory) at its own initiative. The allocated memory is used
> > as long as the software is running. I do not allocate new memory for
> > each new DMA transfer, but at startup a large piece of memory is
> > allocated and the physical addresses are written to the FPGA by the
> > driver software.
>
> Sounds like you are doing something like a circular buffer in memory whic=
h stays
> alive as long as your device does?
>
>
>
> > And yes, we use a DMA adapter in combination with the
> > GetScatterGatherList method. We already used this in another project
> > but that was PCI and DMA read (data from PC memory to FPGA).
>
> > By the way, where can I set the type of DMA?
>
> Typically, you set the DMA buffering method in your AddDevice function af=
ter you
> create your device object. Quoting from Oney's book,
>
> NTSTATUS AddDevice(..) {
> =A0 =A0PDEVICE_OBJECT =A0 =A0fdo;
>
> =A0 =A0IoCreateDevice(....., &fdo);
> =A0 =A0fdo->Flags |=3D DO_BUFFERED_IO;
> =A0 =A0 =A0 =A0 =A0 =A0 <or>
> =A0 =A0fdo->Flags |=3D DO_DIRECT_IO;
> =A0 =A0 =A0 =A0 =A0 =A0 <or>
> =A0 =A0fdo->Flags |=3D 0; =A0// i.e. neither Direct nor Buffered
>
> And, you can't change your mind afterwards.
>
> By the way if my assumption about the circular buffer in your design is c=
orrect,
> there is a slightly more standard solution (standard in the sense that ev=
erybody
> on the microsoft drivers newgroup seems to do it). It however requires tw=
o threads
> in your application. The first one requests a buffer (using new or malloc=
) and
> sets up an I/O Request ReadFile, WriteFile or DeviceIoControl referencing=
 this
> buffer. This is performed as an asynchronous request.
>
> The driver recognises this request and pends it indefinitely, (typically =
terminate
> it when your driver is shutting down, otherwise windows will probably han=
g).
> Pending the request has the nice side effect that the buffer now becomes =
locked
> down permanently.
>
> Assuming you have set up your driver to use DO_DIRECT_IO DMA, you can get=
 the S/G
> list describing the application space buffer as you are currently doing a=
nd feed
> this to your FPGA.
>
> Using the second thread in your application you can constantly read data =
from the
> locked down pages (you app. space buffer) that are being written by your =
FPGA.
>
> Assuming the DO_DIRECT_IO solves your problem (I think there is a good ch=
ance), I
> would however still consider migrating to a KMDF based driver, particular=
ily if
> you are writing a new one. It's much easier to maintain and is probably m=
ore
> portable for future MS versions.
>
>
>
> > best regards,
>
> > Frank
>
> best regards,
> Charles

Hi Charles,

We tried your suggestion (we were using BUFFERED_IO). Unfortunately it
was not the (final) solution. Perhaps there are more causes for the
problem. Anyway, thanks for your suggestion. We are almost out of
ideas of what we can test. Do you have other ideas or tests we can do
to find the cause? I hope to fix the problem before my vacation (only
one day left :)

best regards,

Frank

Article: 148304
Subject: Re: DMA operation to 64-bits PC platform
From: Charles Gardiner <charles.gardiner@invalid.invalid>
Date: Tue, 06 Jul 2010 11:31:50 +0200
Links: << >>  << T >>  << A >>
Frank van Eijkelenburg schrieb:

> We tried your suggestion (we were using BUFFERED_IO). Unfortunately it
> was not the (final) solution. 

Was there any noticeable change in the behaviour at all?

Is it still valid that your FPGA can _read_ data from the buffer when your
application writes it there?

With DO_DIRECT_IO specified, it's not clear to me off-hand why you are not seeing
the memory locations in both directions now.

Perhaps there are more causes for the
> problem. Anyway, thanks for your suggestion. We are almost out of
> ideas of what we can test. Do you have other ideas or tests we can do
> to find the cause? I hope to fix the problem before my vacation (only
> one day left :)

Oops, thats tight. I'm just on the way to a customers so I don't have my usual
references at hand. Have you tried the flush (zero length read from FPGA) after a
write to memory. Although, to be honest I don't think that's the solution (just a
straw to grab for in case your system has some caching behaviour I haven't seen
before). My last (KMDF based) design was similar to yours. The FPGA was streaming
to memory and the SW application reading from the buffer shared between
application memory and kernel memory. I never had any data loss, even without the
zero length read.

If you can send me as much relevant info as possible, I'll have another look this
evening.

Regards,
Charles

Article: 148305
Subject: Re: DMA operation to 64-bits PC platform
From: Michael S <already5chosen@yahoo.com>
Date: Tue, 6 Jul 2010 02:44:38 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Jul 6, 11:00=A0am, Frank van Eijkelenburg
<fei.technolut...@gmail.com> wrote:
> On Jul 2, 9:04=A0pm, Charles Gardiner <charles.gardi...@invalid.invalid>
> wrote:
>
>
>
> > Hi Frank,
>
> > > I am not sure if we understand each other.
>
> > Yes, it certainly sounds like that.
>
> > > What do you mean by
> > > completing the request with IoCompleteRequest? There is no request
> > > from software point of view.
>
> > I think this might clear up the reason why your data is missing. (See a=
lso below
> > about the type of DMA). I don't think the S/G list you are getting is d=
escribing
> > your application buffer. This is best done by specifying DO_DIRECT_IO a=
s the DMA
> > method for your device. If you specify DO_BUFFERED_IO you will get an S=
/G List
> > describing an intermediate buffer in kernel space and this probably nev=
er gets
> > copied over to your application space buffer unless you terminate the r=
equest.
> > I've never done the 'neither' method myself and from what I hear, it's =
a
> > complicated beast.
>
> > > The FPGA will do a DMA write (data from
> > > FPGA to PC memory) at its own initiative. The allocated memory is use=
d
> > > as long as the software is running. I do not allocate new memory for
> > > each new DMA transfer, but at startup a large piece of memory is
> > > allocated and the physical addresses are written to the FPGA by the
> > > driver software.
>
> > Sounds like you are doing something like a circular buffer in memory wh=
ich stays
> > alive as long as your device does?
>
> > > And yes, we use a DMA adapter in combination with the
> > > GetScatterGatherList method. We already used this in another project
> > > but that was PCI and DMA read (data from PC memory to FPGA).
>
> > > By the way, where can I set the type of DMA?
>
> > Typically, you set the DMA buffering method in your AddDevice function =
after you
> > create your device object. Quoting from Oney's book,
>
> > NTSTATUS AddDevice(..) {
> > =A0 =A0PDEVICE_OBJECT =A0 =A0fdo;
>
> > =A0 =A0IoCreateDevice(....., &fdo);
> > =A0 =A0fdo->Flags |=3D DO_BUFFERED_IO;
> > =A0 =A0 =A0 =A0 =A0 =A0 <or>
> > =A0 =A0fdo->Flags |=3D DO_DIRECT_IO;
> > =A0 =A0 =A0 =A0 =A0 =A0 <or>
> > =A0 =A0fdo->Flags |=3D 0; =A0// i.e. neither Direct nor Buffered
>
> > And, you can't change your mind afterwards.
>
> > By the way if my assumption about the circular buffer in your design is=
 correct,
> > there is a slightly more standard solution (standard in the sense that =
everybody
> > on the microsoft drivers newgroup seems to do it). It however requires =
two threads
> > in your application. The first one requests a buffer (using new or mall=
oc) and
> > sets up an I/O Request ReadFile, WriteFile or DeviceIoControl referenci=
ng this
> > buffer. This is performed as an asynchronous request.
>
> > The driver recognises this request and pends it indefinitely, (typicall=
y terminate
> > it when your driver is shutting down, otherwise windows will probably h=
ang).
> > Pending the request has the nice side effect that the buffer now become=
s locked
> > down permanently.
>
> > Assuming you have set up your driver to use DO_DIRECT_IO DMA, you can g=
et the S/G
> > list describing the application space buffer as you are currently doing=
 and feed
> > this to your FPGA.
>
> > Using the second thread in your application you can constantly read dat=
a from the
> > locked down pages (you app. space buffer) that are being written by you=
r FPGA.
>
> > Assuming the DO_DIRECT_IO solves your problem (I think there is a good =
chance), I
> > would however still consider migrating to a KMDF based driver, particul=
arily if
> > you are writing a new one. It's much easier to maintain and is probably=
 more
> > portable for future MS versions.
>
> > > best regards,
>
> > > Frank
>
> > best regards,
> > Charles
>
> Hi Charles,
>
> We tried your suggestion (we were using BUFFERED_IO).

If you were using BUFFERED_IO why was your driver locking the pages?
In case of BUFFERED_IO the pages come from kernel non-paged pool and
don't have to be specifically locked. The only case where the driver
is responsible for locking/unlocking pages is NEITHER I/O.

>Unfortunately it
> was not the (final) solution. Perhaps there are more causes for the
> problem. Anyway, thanks for your suggestion. We are almost out of
> ideas of what we can test. Do you have other ideas or tests we can do
> to find the cause? I hope to fix the problem before my vacation (only
> one day left :)
>
> best regards,
>
> Frank

Another typical mistake is driver forgets to call IoMarkIrpPending().
KMDF does it automatically, but in  plain WDM it's responsibility of
your driver. However forgotten IoMarkIrpPending() normally shows
different symptoms.



Article: 148306
Subject: Re: DMA operation to 64-bits PC platform
From: Michael S <already5chosen@yahoo.com>
Date: Tue, 6 Jul 2010 03:12:44 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Jul 6, 11:00=A0am, Frank van Eijkelenburg
<fei.technolut...@gmail.com> wrote:

> I hope to fix the problem before my vacation (only one day left :)
>

Something, I most certainly DO NOT RECOMMEND for final solution, but
it could help to go to vacation in better mood.
Scrap all the schoolbook nice&complex Windows DMA API stuff. Instead,
take your Irp->MdlAddress, do MmGetMdlPfnArray() and access physical
addresses directly. It's wrong, it's immoral but on simple x86/x64 PC
or on small dual-processor server it always work.
Just don't forget to bring back the official DMA API when you are back
from vocation and have more time than a few hours.

Article: 148307
Subject: Re: Difference between DDR and DDR2
From: Fred <fred__bloggs@lycos.com>
Date: Tue, 6 Jul 2010 03:41:32 -0700 (PDT)
Links: << >>  << T >>  << A >>
On 5 July, 20:53, Gabor <ga...@alacron.com> wrote:
> On Jul 5, 8:21=A0am, Fred <fred__blo...@lycos.com> wrote:
>
>
>
>
>
> > On 5 July, 11:45, "maxascent"
>
> > <maxascent@n_o_s_p_a_m.n_o_s_p_a_m.yahoo.co.uk> wrote:
> > > I have used DDR2 but not DDR but I am fairly sure that the init seq i=
s
> > > different. I wouldnt be surprised if there are different timings and =
burst
> > > types too. Because of the faster timings on DDR2 some form of read
> > > calibration would be needed. So you could probably modify a DDR contr=
oller
> > > but using it straight out of the box is not possible.
>
> > > Jon =A0 =A0 =A0 =A0
>
> > > --------------------------------------- =A0 =A0 =A0 =A0
> > > Posted throughhttp://www.FPGARelated.com
>
> > I have control over the initialisation sequence so that should not be
> > an issue. I also have control over the clock and strobe timings as
> > well.
>
> > You haven't outlined any show-stoppers that I might have expected.
>
> > Many thanks for your view.
>
> I think you may be able to configure the DQS as single-ended, but
> normally
> DDR2 uses differential DQS signals. =A0Also on-die termination was added
> in
> DDR2, this requires an extra signal if you use it. =A0The start-up
> sequences are
> different and the DDR2 has more mode registers.
>
> Regards,
> Gabor- Hide quoted text -
>

A Micron datasheet suggests that the DQS# need not be used where the
option has been chosen in the Mode Register, implying that single
ended strobe operation would be fine.

I have control over the start-up sequence so this should not be an
issue.

Given I only anticipate using a single rank of memory, I had hoped
that I could assert ODT once the extended mode register had been
written.  I don't anticipate using self-refresh which also requires
ODT to be pulled during refresh.

Many thanks.



Article: 148308
Subject: FPGA Video processing board (HDMI).. who makes one?
From: "alangeering" <alan@n_o_s_p_a_m.algee.co.uk>
Date: Tue, 06 Jul 2010 11:31:48 -0500
Links: << >>  << T >>  << A >>
Does anyone make the following:

HDMI Receiver -> FPGA -> HDMI Transmitter

I would considder DVI/Displayport also.

I just want this for video processing. I don't need audio, controls, PCIe,
etc.
I've seen some very large boards with HDMI daughter boards but they're way
too large and unnecessary for just testing video algorithms.

Thanks, Alan Geering

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

Article: 148309
Subject: spartan 3xc3s4000 daisy chain help required
From: "salimbaba" <a1234573@n_o_s_p_a_m.owlpic.com>
Date: Tue, 06 Jul 2010 11:31:56 -0500
Links: << >>  << T >>  << A >>
Hi,

I am using spartan 3 FPGAs  and 1 EEPROM XCF16P in daisy chain
configuration and programming it through JTAG but i am getting this error
continuously " DONE did not go high".The TDI of JTAG is connected to TDI of
EEPROM, TDO of EEPROM is connected to TDI of FPGA1 and so on. I have double
checked the hardware but i cant seem to solve it. The devices are in this
order:

EEPROM -> FPGA1 -> FPGA2


any pointers or solutions ?


thanks

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

Article: 148310
Subject: 6 kbytes BRAM and Xst:2260
From: "aleksa" <aleksazr@gmail.com>
Date: Tue, 6 Jul 2010 21:09:24 +0200
Links: << >>  << T >>  << A >>
I'm using Coregen on XC2S200 to generate a 6144 bytes (12 blocks)
BRAM and I get these infos:

INFO:Xst:2260 - The FF/Latch <BU16> in Unit <test> is
equivalent to the following 3 FFs/Latches : <BU97> <BU178> <BU259>

INFO:Xst:2260 - The FF/Latch <BU19> in Unit <test> is
equivalent to the following 3 FFs/Latches : <BU100> <BU181> <BU262>

INFO:Xst:2260 - The FF/Latch <BU16> in Unit <test> is
equivalent to the following 3 FFs/Latches : <BU97> <BU178> <BU259>

INFO:Xst:2260 - The FF/Latch <BU19> in Unit <test> is
equivalent to the following 3 FFs/Latches : <BU100> <BU181> <BU262>


I didn't create those BUxx FF/Latches, presumably they are internal to ISE.

6144 bytes requires 13 address lines and 2^13 = 8192 which means that
I can actually access the same memory with diff. addresses.
Is that what ISE is trying to tell me? Because, if I create,
for example, 1025 (1024+1) bytes BRAM w/ 11 address lines
then I don't get those infos.

Using ISE 10.1.03 



Article: 148311
Subject: Re: spartan 3xc3s4000 daisy chain help required
From: Symon <symon_brewer@hotmail.com>
Date: Wed, 07 Jul 2010 01:48:28 +0100
Links: << >>  << T >>  << A >>
UG332

Article: 148312
Subject: Re: spartan 3xc3s4000 daisy chain help required
From: Gabor <gabor@alacron.com>
Date: Tue, 6 Jul 2010 19:23:16 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Jul 6, 12:31=A0pm, "salimbaba" <a1234573@n_o_s_p_a_m.owlpic.com>
wrote:
> Hi,
>
> I am using spartan 3 FPGAs =A0and 1 EEPROM XCF16P in daisy chain
> configuration and programming it through JTAG but i am getting this error
> continuously " DONE did not go high".The TDI of JTAG is connected to TDI =
of
> EEPROM, TDO of EEPROM is connected to TDI of FPGA1 and so on. I have doub=
le
> checked the hardware but i cant seem to solve it. The devices are in this
> order:
>
> EEPROM -> FPGA1 -> FPGA2
>
> any pointers or solutions ?
>
> thanks
>
> --------------------------------------- =A0 =A0 =A0 =A0
> Posted throughhttp://www.FPGARelated.com

If you daisy-chain FPGA's and connect the DONE pins together, you
should always program
both FPGA's in the same impact command (from JTAG).  Using the GUI you
would select
both FPGA's in the diagram and then double-click program in the
processes pane.

If you want to program one FPGA at a time, you can modify the bitgen
settings for
"enable internal DONE pipe" so the FPGA doesn't wait for the other
FPGA to finish
configuration before startup.  Obviously for the EEPROM to work, you
need to chain
the bitstreams together.

HTH,
Gabor

Article: 148313
Subject: Re: 6 kbytes BRAM and Xst:2260
From: Gabor <gabor@alacron.com>
Date: Tue, 6 Jul 2010 19:30:19 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Jul 6, 3:09=A0pm, "aleksa" <aleks...@gmail.com> wrote:
> I'm using Coregen on XC2S200 to generate a 6144 bytes (12 blocks)
> BRAM and I get these infos:
>
> INFO:Xst:2260 - The FF/Latch <BU16> in Unit <test> is
> equivalent to the following 3 FFs/Latches : <BU97> <BU178> <BU259>
>
> INFO:Xst:2260 - The FF/Latch <BU19> in Unit <test> is
> equivalent to the following 3 FFs/Latches : <BU100> <BU181> <BU262>
>
> INFO:Xst:2260 - The FF/Latch <BU16> in Unit <test> is
> equivalent to the following 3 FFs/Latches : <BU97> <BU178> <BU259>
>
> INFO:Xst:2260 - The FF/Latch <BU19> in Unit <test> is
> equivalent to the following 3 FFs/Latches : <BU100> <BU181> <BU262>
>
> I didn't create those BUxx FF/Latches, presumably they are internal to IS=
E.
>
> 6144 bytes requires 13 address lines and 2^13 =3D 8192 which means that
> I can actually access the same memory with diff. addresses.
> Is that what ISE is trying to tell me? Because, if I create,
> for example, 1025 (1024+1) bytes BRAM w/ 11 address lines
> then I don't get those infos.
>
> Using ISE 10.1.03

Never try to second-guess the inner workings of Coregen.  These cores
are not optimised
and generally give more warnings due to unconnected ports, etc.  Learn
to live with
the warnings as long as the memory does what you want.  If I had to
guess, the "info's"
happen when you have enough memory defined to require fabric-based
multiplexing
rather than just a bunch of instantiated block RAM primitives.

The "BU..." are very informative names generated in loops in the
coregen code ;-)
I generally ignore all warnings with BU in the net names.  If you
don't want to
have warnings, generate your own RAM's using inference or instantiated
primitives.

Regards,
Gabor

Article: 148314
Subject: Re: spartan 3xc3s4000 daisy chain help required
From: "salimbaba" <a1234573@n_o_s_p_a_m.n_o_s_p_a_m.owlpic.com>
Date: Wed, 07 Jul 2010 00:28:06 -0500
Links: << >>  << T >>  << A >>
ok thanks Gabor .

i tried to program them together but no success , also, i have already
tried the DONE internal pipe thing, i cant seem to figure out the problem.
Is there any way i can show you the schematic, u may be able to see the
problem because i haven't been able to catch it for the last 1 week =(


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

Article: 148315
Subject: Re: xilinx leadtimes
From: rickman <gnuarm@gmail.com>
Date: Tue, 6 Jul 2010 23:11:22 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Jul 5, 6:57 am, Michael S <already5cho...@yahoo.com> wrote:
> On Jul 5, 2:37 am, rickman <gnu...@gmail.com> wrote:
>
>
>
> > What's the lead time for Spartan 5 parts?
>
> Don't you mean Spartan 3E?
>
> > Or how about Altera or
> > Lattice parts?  Why look for trouble?
>
> > Rick
>
> Don't know about Lattice.
>
> As to Altera, Spartan 6 has many features not available in Cyclone2/3.
> Lead time for Cyclone IV is probably not much shorter than for Spartan
> 6. Also, Spartan 6 is both build on more modern silicon process and
> has more advanced LUT architecture than even Cyclone IV, so, in
> theory, it should be faster.
> Of course, there is Arria II GX that easily matches (and beats)
> Spartan 6 feature4feature and MHz4Mhz. It is even sort of available,
> at least some parts. However, Arria II GX is more like mid-cost device
> rather than low-cost.

Yeah, right...  In theory, theory and practice are the same.  In
practice, they differ considerably.  I have found that other than
application specific features like SERDES or MACs, I don't see a real
advantage for them.  Sure they may let me use the next size smaller
device and the newer parts in finer pitch geometries "should" save me
money, but if I can't get the parts I lose much more money than I
"lose" using a less advanced device.  As to the speed, I am finding
that the speed increases of newer parts are minimal and I haven't had
a design that pushed the device speeds in over five years.  Of course
that depends entirely on the design being developed.

I can't use any part, no matter how good it is, if I can't get it.
Production needs beat design requirements any day.

Rick

Article: 148316
Subject: Re: FPGA Video processing board (HDMI).. who makes one?
From: backhus <goouse99@googlemail.com>
Date: Tue, 6 Jul 2010 23:16:44 -0700 (PDT)
Links: << >>  << T >>  << A >>
On 6 Jul., 18:31, "alangeering" <alan@n_o_s_p_a_m.algee.co.uk> wrote:
> Does anyone make the following:
>
> HDMI Receiver -> FPGA -> HDMI Transmitter
>
> I would considder DVI/Displayport also.
>
> I just want this for video processing. I don't need audio, controls, PCIe=
,
> etc.
> I've seen some very large boards with HDMI daughter boards but they're wa=
y
> too large and unnecessary for just testing video algorithms.
>
> Thanks, Alan Geering
>
> --------------------------------------- =A0 =A0 =A0 =A0
> Posted throughhttp://www.FPGARelated.com

Hi Alan,
There were nice solutions available for DVI. (e.g. Inrevium Boards)
They are also not cheap, but they offer the daughter boards extra or
at least publish the schematics:
http://www.inrevium.jp/eng/x-fpga-board/optional_board.html

You could adapt these boards to cheaper starter kits, Or you could
build your own adapter boards.
They are mainly based on TI's DVI-RGB(24bit) conversion chips. Maybe
they have similar chips now for HDMI or Displayport.

Have a nice synthesis
  Eilert

Article: 148317
Subject: EEBlaster - USB-JTAG-tool for Altera
From: Thomas Entner <thomas.entner@entner-electronics.com>
Date: Wed, 7 Jul 2010 00:51:57 -0700 (PDT)
Links: << >>  << T >>  << A >>
HOT SUMMER OFFER

To all the Altera users here: If you order at least 3 EEBlasters
(EUR49,-/pcs), you will get free shipping inside Europe, when you
mention "HOT SUMMER" in the remarks-field of the order form.

The EEBlaster can be ordered at:
http://www.entner-electronics.com/tl/index.php/eeblaster.html

The offer is valid until 30th September 2010 (we know, it is quite
optimistic for hot summer, but nevermind...)

Regards,

Thomas

P.S.: Distributors are welcome, custom labeling is possible.

Article: 148318
Subject: Re: xilinx leadtimes
From: Mike Harrison <mike@whitewing.co.uk>
Date: Wed, 07 Jul 2010 10:06:44 +0100
Links: << >>  << T >>  << A >>
On Tue, 6 Jul 2010 23:11:22 -0700 (PDT), rickman <gnuarm@gmail.com> wrote:

>On Jul 5, 6:57 am, Michael S <already5cho...@yahoo.com> wrote:
>> On Jul 5, 2:37 am, rickman <gnu...@gmail.com> wrote:
>>
>>
>>
>> > What's the lead time for Spartan 5 parts?
>>
>> Don't you mean Spartan 3E?
>>
>> > Or how about Altera or
>> > Lattice parts?  Why look for trouble?
>>
>> > Rick
>>
>> Don't know about Lattice.
>>
>> As to Altera, Spartan 6 has many features not available in Cyclone2/3.
>> Lead time for Cyclone IV is probably not much shorter than for Spartan
>> 6. Also, Spartan 6 is both build on more modern silicon process and
>> has more advanced LUT architecture than even Cyclone IV, so, in
>> theory, it should be faster.
>> Of course, there is Arria II GX that easily matches (and beats)
>> Spartan 6 feature4feature and MHz4Mhz. It is even sort of available,
>> at least some parts. However, Arria II GX is more like mid-cost device
>> rather than low-cost.
>
>Yeah, right...  In theory, theory and practice are the same.  In
>practice, they differ considerably.  I have found that other than
>application specific features like SERDES or MACs, I don't see a real
>advantage for them.  Sure they may let me use the next size smaller
>device and the newer parts in finer pitch geometries "should" save me
>money, but if I can't get the parts I lose much more money than I
>"lose" using a less advanced device.  As to the speed, I am finding
>that the speed increases of newer parts are minimal and I haven't had
>a design that pushed the device speeds in over five years.  Of course
>that depends entirely on the design being developed.
>
>I can't use any part, no matter how good it is, if I can't get it.
>Production needs beat design requirements any day.
>
>Rick

And once a company gets a reputation for announcing vapourware, nobody will even bother loooking at
any new products they may announce. 

Article: 148319
Subject: Re: FPGA Video processing board (HDMI).. who makes one?
From: Martin Thompson <martin.j.thompson@trw.com>
Date: Wed, 07 Jul 2010 10:15:06 +0100
Links: << >>  << T >>  << A >>
"alangeering" <alan@n_o_s_p_a_m.algee.co.uk> writes:

> Does anyone make the following:
>
> HDMI Receiver -> FPGA -> HDMI Transmitter
>
> I would considder DVI/Displayport also.
>
> I just want this for video processing. I don't need audio, controls, PCIe,
> etc.

If you'll excuse the commercial - and if a S3ADSP 3400 is big enough
and fast enough for your needs - our T Cam Stereo is close to what you
want:

http://www.conekt.co.uk/images/stories/Products_FILES/t%20cam%20stereo_web.pdf

You don't have to have the cameras if you don't want them :)

I already have a DVI output board, and could develop a DVI input board
if required.  Or we could do a HDMI I/O board for you instead.

> I've seen some very large boards with HDMI daughter boards but they're way
> too large and unnecessary for just testing video algorithms.
>

I take it the Xilinx Video Starter Kit is too large?  That has DVI in
and out IIRC.

Cheers,
Martin

-- 
martin.j.thompson@trw.com 
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.conekt.co.uk/capabilities/39-electronic-hardware


Article: 148320
Subject: LXT972 pass-through packet
From: "leoeltipo" <leoeltipo@n_o_s_p_a_m.gmail.com>
Date: Wed, 07 Jul 2010 05:19:50 -0500
Links: << >>  << T >>  << A >>
Hello. I have designed an ethernet interface with a Xilinx Virtex 5 FPGA
and a LXT972 Intel's IC. Besides,  I have a GUI designed in the computer
host to send/receive files and information.

Using a sniffer, I can see sometimes that data coming back from the board
is read as pass-through packets, instead of having the right direction
(input).

Could someone help me?

I'm sorry if the question is not relevant, is the first time I'm posting.


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

Article: 148321
Subject: Re: FPGA Video processing board (HDMI).. who makes one?
From: Anssi Saari <as@pepper.modeemi.fi>
Date: Wed, 07 Jul 2010 14:07:52 +0300
Links: << >>  << T >>  << A >>
"alangeering" <alan@n_o_s_p_a_m.algee.co.uk> writes:

> Does anyone make the following:
>
> HDMI Receiver -> FPGA -> HDMI Transmitter
>
> I would considder DVI/Displayport also.
>
> I just want this for video processing. I don't need audio, controls, PCIe,
> etc.

I just ran accross this (the company advertized their eeblaster deal
here): http://www.entner-electronics.com/tl/index.php/ipp_1.html

DVI or VGA in and out, Cyclone III FPGA. No price info, though.

Article: 148322
Subject: SPF+ useable signalling range
From: "Roger" <rogerwilson@hotmail.com>
Date: Wed, 7 Jul 2010 14:04:47 +0100
Links: << >>  << T >>  << A >>
Anyone know about FO transceivers?

The Finisar (and other SFP/SFP+ FOTs come in particular frequencies) - e.g. 
8.5Gbps for the FTLF8528P2BNV. Can these parts still be used for lower 
frequencies, say 6.5Gbps for Xilinx GTP RocketIO links please?

Has anyone any proven solutions of using a FOT for 6.5Gbps RIO links?

Thanks. 


Article: 148323
Subject: Re: SPF+ useable signalling range
From: John McCaskill <jhmccaskill@gmail.com>
Date: Wed, 7 Jul 2010 06:46:56 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Jul 7, 8:04=A0am, "Roger" <rogerwil...@hotmail.com> wrote:
> Anyone know about FO transceivers?
>
> The Finisar (and other SFP/SFP+ FOTs come in particular frequencies) - e.=
g.
> 8.5Gbps for the FTLF8528P2BNV. Can these parts still be used for lower
> frequencies, say 6.5Gbps for Xilinx GTP RocketIO links please?
>
> Has anyone any proven solutions of using a FOT for 6.5Gbps RIO links?
>
> Thanks.


Hello Roger,

While I have not tried that specific module, we have several products
that use SFP and SFP+, and my experience is that the optical modules
are quite happy to run at lower speeds. I don't know how low they will
go, but many of them are rated at multiple rates, ie 2 and 4 Gbs or 4
and 8Gbs.

You can use ChipScope Pro and the IBERT tool to try out a specific SFP
+ module quickly. If you have the ML605 development board, there are
reference designs and documentation that describe how to do this. It
also has one SFP connector on it.  The ML605 has the slowest speed
grade part on it that is only rated at 5 Gbs, but we used an ML605,
IBERT, and one of these : http://www.fastertechnology.com/fmc.html to
get four lanes running at over 7 Gbs.


Regards,

John McCaskill
www.FasterTechnology.com

Article: 148324
Subject: Re: xilinx leadtimes
From: Uwe Bonnes <bon@elektron.ikp.physik.tu-darmstadt.de>
Date: Wed, 7 Jul 2010 14:54:57 +0000 (UTC)
Links: << >>  << T >>  << A >>
Mike Harrison <mike@whitewing.co.uk> wrote:

> And once a company gets a reputation for announcing vapourware, 
> nobody will even bother loooking at
> any new products they may announce. 

You overestimate the ability of people to learn from the past. With each new
announcment sales people will announce that they learned from the past and
everything is better now, and users will gladly believe them.

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

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



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