Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
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
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
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
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
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: 148304Frank 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, CharlesArticle: 148305
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: 148306On 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
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
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.comArticle: 148309
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.comArticle: 148310
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.03Article: 148311
UG332Article: 148312
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, GaborArticle: 148313
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, GaborArticle: 148314
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.comArticle: 148315
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. RickArticle: 148316
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 EilertArticle: 148317
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
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
"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-hardwareArticle: 148320
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.comArticle: 148321
"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
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
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.comArticle: 148324
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:
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