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 144675

Article: 144675
Subject: Re: Please help, Xilinx FIFO problem!
From: John_H <newsgroup@johnhandwork.com>
Date: Tue, 22 Dec 2009 05:14:45 -0800 (PST)
Links: << >>  << T >>  << A >>
On Dec 22, 8:06=A0am, John_H <newsgr...@johnhandwork.com> wrote:
> On Dec 22, 12:00=A0am, Antti <antti.luk...@googlemail.com> wrote:
>
>
>
> > On Dec 22, 6:40=A0am, John_H <newsgr...@johnhandwork.com> wrote:
>
> > > Sometimes the simpler things can get in the way of complex issues.
>
> > > Are you certain your read enable and write enables are showing up
> > > relative to the correct data?
> > > It seems some people expect the read enable to indicate the valid dat=
a
> > > is being removed from the FIFO while others believe the read enable
> > > should produce valid data on the following clock.
>
> > > Double check where the documentation says the valid data should be
> > > relative to the enable pulse especially for the read, but check the
> > > write as well.
> > > ___
>
> > > How deep do you want your FIFO?
> > > Is latency an issue?
> > > Do you want rd_en to indicate you're taking valid data or that the
> > > next clock is valid?
> > > You want wr_en to be present in the same clock cycle as the din,
> > > right?
>
> > > Long time no post (partly because I miss having a real newsreader),
> > > - John_H
>
> > Hi John,
>
> > 1 the FIFO is supposed to be SIMPLEST possible MGT receiver, FIFO
> > wr_en is active when the incoming char is not IDLE.
> > 2 Latency is absolutly NO issue, PPC is pulling the data extremly slow
> > anyway :(
> > 3 rd_en almost do not care, well currently it is wrong, 1 clock too
> > late so PPC doesnt pull the last value from fifo (it is pulled when
> > new data comes in), but this minor issue does really not explain the
> > error where the fifo reads out out half of the old values
>
> > Antti
>
> If the rd_en is one cycle off, the data during that cycle is
> undefined.
>
> If the rd_en is active for two cycles, the data extracted will be
> precisely one cycle off for the rd_en pulses after the first.
>
> The specific FIFO implementation may provide what looks like valid
> data - or not - during the first of those consecutive rd_en pulses.
>
> I would *love* to know how much data is "good" versus "bad" with the
> rd_en realigned.
>
> - John_H

Rereading some stuff, perhaps I wasn't clear:  the data for a read
pulse may be expected by the system the same clock as the read enable
- indicating the design is "taking valid data" from the FIFO on that
clock where rd_en and dout are both valid the same clock cycle - while
the FIFO expects the dout to be valid the clock *after* the rd_en. Or
vice-versa.

It's this "which clock cycle" issue between rd_en and the dout
corresponding to that rd_en that trips up some engineers.

Article: 144676
Subject: Re: Please help, Xilinx FIFO problem!
From: Antti <antti.lukats@googlemail.com>
Date: Tue, 22 Dec 2009 05:20:13 -0800 (PST)
Links: << >>  << T >>  << A >>
On Dec 22, 3:06=A0pm, John_H <newsgr...@johnhandwork.com> wrote:
> On Dec 22, 12:00=A0am, Antti <antti.luk...@googlemail.com> wrote:
>
>
>
>
>
> > On Dec 22, 6:40=A0am, John_H <newsgr...@johnhandwork.com> wrote:
>
> > > Sometimes the simpler things can get in the way of complex issues.
>
> > > Are you certain your read enable and write enables are showing up
> > > relative to the correct data?
> > > It seems some people expect the read enable to indicate the valid dat=
a
> > > is being removed from the FIFO while others believe the read enable
> > > should produce valid data on the following clock.
>
> > > Double check where the documentation says the valid data should be
> > > relative to the enable pulse especially for the read, but check the
> > > write as well.
> > > ___
>
> > > How deep do you want your FIFO?
> > > Is latency an issue?
> > > Do you want rd_en to indicate you're taking valid data or that the
> > > next clock is valid?
> > > You want wr_en to be present in the same clock cycle as the din,
> > > right?
>
> > > Long time no post (partly because I miss having a real newsreader),
> > > - John_H
>
> > Hi John,
>
> > 1 the FIFO is supposed to be SIMPLEST possible MGT receiver, FIFO
> > wr_en is active when the incoming char is not IDLE.
> > 2 Latency is absolutly NO issue, PPC is pulling the data extremly slow
> > anyway :(
> > 3 rd_en almost do not care, well currently it is wrong, 1 clock too
> > late so PPC doesnt pull the last value from fifo (it is pulled when
> > new data comes in), but this minor issue does really not explain the
> > error where the fifo reads out out half of the old values
>
> > Antti
>
> If the rd_en is one cycle off, the data during that cycle is
> undefined.
>
> If the rd_en is active for two cycles, the data extracted will be
> precisely one cycle off for the rd_en pulses after the first.
>
> The specific FIFO implementation may provide what looks like valid
> data - or not - during the first of those consecutive rd_en pulses.
>
> I would *love* to know how much data is "good" versus "bad" with the
> rd_en realigned.
>
> - John_H

John,

just LAST value remains in the FIFO nothing else wrong, this really
is not an issue the system, the data corruption is NEVER wrong values.

1) double value
2) 1, 2, 3 missing values
3) rd addr ptr restart at random

So ALL data what comes is good in that sense its data that has been
pushed it. its just duplicates, missing or long repeats of old data.

whatever the read enable is clock early or late it can not be cause
the cause of the problem. I can also call it design feature if you so
want. We read the data, and pop next one. Ok, its little buggy feature
but several big companies call serious bugs a feature.

Antti

Article: 144677
Subject: Re: Please help, Xilinx FIFO problem!
From: John_H <newsgroup@johnhandwork.com>
Date: Tue, 22 Dec 2009 05:55:32 -0800 (PST)
Links: << >>  << T >>  << A >>
On Dec 22, 8:20=A0am, Antti <antti.luk...@googlemail.com> wrote:
> John,
>
> just LAST value remains in the FIFO nothing else wrong, this really
> is not an issue the system, the data corruption is NEVER wrong values.
>
> 1) double value
> 2) 1, 2, 3 missing values
> 3) rd addr ptr restart at random
>
> So ALL data what comes is good in that sense its data that has been
> pushed it. its just duplicates, missing or long repeats of old data.
>
> whatever the read enable is clock early or late it can not be cause
> the cause of the problem. I can also call it design feature if you so
> want. We read the data, and pop next one. Ok, its little buggy feature
> but several big companies call serious bugs a feature.
>
> Antti

If you haven't gotten the FIFO working yet, I'd love to bring up my
VHDL coding with a FIFO to help you out within the next several
hours.  You gave the port declarations but I didn't see your needed
FIFO depth.  And is valid data the clock after the rd_en acceptable?

It's good for me to get into VHDL and it sounds like you could use a
little Christmas cheer.  I've done Verilog FIFOs in the past with rock-
solid results.  Full asynch support, read past empty can generate an
"invalid read" flag but not upset the later operation (for an absurd
method of "clearing out a FIFO" for instance) while write past full
will be entirely gated out with an error flag the following clock.

- John_H

Article: 144678
Subject: Strange behavior with serial ADC chip select and MISO pin
From: Nicholas Kinar <n.kinar@usask.ca>
Date: Tue, 22 Dec 2009 09:03:39 -0600
Links: << >>  << T >>  << A >>
Hello--

I am working on a custom board with a Cyclone II FPGA.  Attached to the 
   pins of the FPGA are six serial ADCs (AD7690 from Analog Devices). 
Each ADC has three pins which are controlled by the FPGA: #CS, MISO, 
SCLK and CNV.  I am using the ADCs with the #CS-mode, 3-wire with busy 
signal interface.  This means that a rising edge on CNV will initiate a 
conversion, and since #CS is always held high, a pull-up resistor on 
MISO will allow the ADC to signal to the master when the conversion is 
complete.  This occurs when the ADC MISO output goes from high impedance 
to low impedance, causing the MISO signal to drop logic low.  A data 
word is then read from the ADC by toggling the SCLK.  The data word is 
output on MISO in a synchronous fashion to the SCLK signal.

Strangely enough, it appears that when power is initially applied, MISO 
is low, although the pull-up resistor is present.  With the FPGA not 
programmed, I have noticed that I can touch the #CS input with a 
multimeter probe, and MISO will go high.  This behavior is similar for 
all of the six ADCs.  Note that there is also a pull-up resistor on the 
#CS input.

Using the Quartus II software, I have ensured that all un-used pins are 
tri-stated on startup.  To verify operation, I am using the SignalTap II 
  Logic Analyzer, which is bundled with the Quartus II software.

What is really weird is that according to SignalTap II, the MISO of the 
6th ADC does not want to go high after startup.  All of the other MISO 
outputs of the ADCs go high after startup.  The signal is represented as 
MISO[5] in the Quartus II pin planner, and is an input in the associated 
Verilog code.  Moreover, SignalTap II tells me that the chip select #CS 
output of the 6th ADC is high.  Using Verilog code, I have attempted to 
toggle the #CS of all ADCs.  Doing so causes all MISO outputs of the 
ADCs to drop low (when #CS is low), and then to go high again (when #CS 
is high).  However, according to the SignalTap II logic analyzer, 
MISO[5] remains at logic low.

I have verified the connections from the FPGA to the ADCs, and all 
connections seem to be good.

However, I have noticed some strange warnings in the Quartus II software:

-------
Warning: Can't achieve timing requirement Clock Setup: 
'my_pll:pll|altpll:altpll_component|_clk0' along 166 path(s). See Report 
window for details.

Warning: Can't achieve timing requirement Clock Setup: 'clk' along 95 
path(s). See Report window for details.

Warning: Circuit may not operate. Detected 76 non-operational path(s) 
clocked by clock "altera_internal_jtag~TCKUTAP" with clock skew larger 
than data delay. See Compilation Report for details.
-------

I suspect that these warnings may indicate that there is a problem with 
the timing analysis.

Would anyone be able to shed some light on why the MISO[5] pin would 
always be at logic low?

What would explain the behavior of touching the #CS pins with the 
multimeter to cause the MISO output to go high?

Nicholas





Article: 144679
Subject: Re: Please help, Xilinx FIFO problem!
From: Antti <antti.lukats@googlemail.com>
Date: Tue, 22 Dec 2009 07:24:45 -0800 (PST)
Links: << >>  << T >>  << A >>
On Dec 22, 3:55=A0pm, John_H <newsgr...@johnhandwork.com> wrote:
> On Dec 22, 8:20=A0am, Antti <antti.luk...@googlemail.com> wrote:
>
>
>
>
>
> > John,
>
> > just LAST value remains in the FIFO nothing else wrong, this really
> > is not an issue the system, the data corruption is NEVER wrong values.
>
> > 1) double value
> > 2) 1, 2, 3 missing values
> > 3) rd addr ptr restart at random
>
> > So ALL data what comes is good in that sense its data that has been
> > pushed it. its just duplicates, missing or long repeats of old data.
>
> > whatever the read enable is clock early or late it can not be cause
> > the cause of the problem. I can also call it design feature if you so
> > want. We read the data, and pop next one. Ok, its little buggy feature
> > but several big companies call serious bugs a feature.
>
> > Antti
>
> If you haven't gotten the FIFO working yet, I'd love to bring up my
> VHDL coding with a FIFO to help you out within the next several
> hours. =A0You gave the port declarations but I didn't see your needed
> FIFO depth. =A0And is valid data the clock after the rd_en acceptable?
>
> It's good for me to get into VHDL and it sounds like you could use a
> little Christmas cheer. =A0I've done Verilog FIFOs in the past with rock-
> solid results. =A0Full asynch support, read past empty can generate an
> "invalid read" flag but not upset the later operation (for an absurd
> method of "clearing out a FIFO" for instance) while write past full
> will be entirely gated out with an error flag the following clock.
>
> - John_H- Hide quoted text -
>
> - Show quoted text -

Hi John,

I have only spare minute, please do not shoote me - when I reported
all 4 FIFOs not working it was wrong, the non-xilinx fifo is not
tested
i replaced the un-unused FIFO

I will retest and report results.
what does look like valid result is that replacing one of 2 similar
FIFOs the unused one, made the other one have 10 times less error

have to give kids e-lectronics class this instant!
Antti












Article: 144680
Subject: Re: Please help, Xilinx FIFO problem!
From: nico@puntnl.niks (Nico Coesel)
Date: Tue, 22 Dec 2009 15:38:08 GMT
Links: << >>  << T >>  << A >>
Antti <antti.lukats@googlemail.com> wrote:

>On Dec 22, 3:55=A0pm, John_H <newsgr...@johnhandwork.com> wrote:
>> On Dec 22, 8:20=A0am, Antti <antti.luk...@googlemail.com> wrote:
>>
>>
>>
>>
>>
>> > John,
>>
>> > just LAST value remains in the FIFO nothing else wrong, this really
>> > is not an issue the system, the data corruption is NEVER wrong values.
>>
>> > 1) double value
>> > 2) 1, 2, 3 missing values
>> > 3) rd addr ptr restart at random
>>
>> > So ALL data what comes is good in that sense its data that has been
>> > pushed it. its just duplicates, missing or long repeats of old data.
>>
>> > whatever the read enable is clock early or late it can not be cause
>> > the cause of the problem. I can also call it design feature if you so
>> > want. We read the data, and pop next one. Ok, its little buggy feature
>> > but several big companies call serious bugs a feature.
>>
>> > Antti
>>
>> If you haven't gotten the FIFO working yet, I'd love to bring up my
>> VHDL coding with a FIFO to help you out within the next several
>> hours. =A0You gave the port declarations but I didn't see your needed
>> FIFO depth. =A0And is valid data the clock after the rd_en acceptable?
>>
>> It's good for me to get into VHDL and it sounds like you could use a
>> little Christmas cheer. =A0I've done Verilog FIFOs in the past with rock-
>> solid results. =A0Full asynch support, read past empty can generate an
>> "invalid read" flag but not upset the later operation (for an absurd
>> method of "clearing out a FIFO" for instance) while write past full
>> will be entirely gated out with an error flag the following clock.
>>
>> - John_H- Hide quoted text -
>>
>> - Show quoted text -
>
>Hi John,
>
>I have only spare minute, please do not shoote me - when I reported
>all 4 FIFOs not working it was wrong, the non-xilinx fifo is not
>tested
>i replaced the un-unused FIFO
>
>I will retest and report results.
>what does look like valid result is that replacing one of 2 similar
>FIFOs the unused one, made the other one have 10 times less error

Does this mean that changing the design had effects in other unaltered
places? If yes, then you definitely have a clock-boundary crossing
problem.

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

Article: 144681
Subject: Re: Please help, Xilinx FIFO problem!
From: John McCaskill <jhmccaskill@gmail.com>
Date: Tue, 22 Dec 2009 07:57:42 -0800 (PST)
Links: << >>  << T >>  << A >>
On Dec 22, 9:24=A0am, Antti <antti.luk...@googlemail.com> wrote:
> On Dec 22, 3:55=A0pm, John_H <newsgr...@johnhandwork.com> wrote:
>

<snip>

>
> Hi John,
>
> I have only spare minute, please do not shoote me - when I reported
> all 4 FIFOs not working it was wrong, the non-xilinx fifo is not
> tested
> i replaced the un-unused FIFO
>
> I will retest and report results.
> what does look like valid result is that replacing one of 2 similar
> FIFOs the unused one, made the other one have 10 times less error
>
> have to give kids e-lectronics class this instant!
> Antti

Since your change did not change the functionality of what you tested,
but changed the timing due to going through place and route again,
this sure sounds like it could be a timing problem to me.

I am sure that you have already checked that static path analysis
stated that all of your constraints were met, so generate a custom
timing report and have it list the unconstrained paths.

If something that matters is unconstrained, you are susceptible to
strange behavior from the design. Since the symptoms are appearing at
a FIFO, I would pay special attention to signals crossing between the
clock domains. You mention that the FPGA is about 80% full. If you
meant 80% of LUTs and FFs, you are getting into the region that the
place and route tools are having to work hard to meet timing
constraints. If something is unconstrained,  it could be getting
really poor placement and timing with respect to what it really needs.

Regards,

John McCaskill
www.FasterTechnology.com

Article: 144682
Subject: Re: Please help, Xilinx FIFO problem!
From: Antti <antti.lukats@googlemail.com>
Date: Tue, 22 Dec 2009 09:32:39 -0800 (PST)
Links: << >>  << T >>  << A >>
snip
> > Antti
>
> Since your change did not change the functionality of what you tested,
> but changed the timing due to going through place and route again,
> this sure sounds like it could be a timing problem to me.
>
> I am sure that you have already checked that static path analysis
> stated that all of your constraints were met, so generate a custom
> timing report and have it list the unconstrained paths.
>
> If something that matters is unconstrained, you are susceptible to
> strange behavior from the design. Since the symptoms are appearing at
> a FIFO, I would pay special attention to signals crossing between the
> clock domains. You mention that the FPGA is about 80% full. If you
> meant 80% of LUTs and FFs, you are getting into the region that the
> place and route tools are having to work hard to meet timing
> constraints. If something is unconstrained, =A0it could be getting
> really poor placement and timing with respect to what it really needs.
>
> Regards,
>
> John McCaskillwww.FasterTechnology.com

not very encouranging, I have had really hard times with Actel devices
where i have witnessed a simple shift register at low as dirt clean
clock
to stop shifting if FPGA utilization did go above say 93% of
versatales.
There was no violations, nothing did show up in post place and route
simulation, just chip was dead. Later i did read about MANUAL
insertion of "inverting" clock tree to adjust the timings. This was
scary!

current design utilization is
Slices 14K 73%
brams 116 80%
DSP 39 80%
GT11 6 50%

the device is slowest speed grade FX40
and there is not a single assembled with higher speed grade, so that
testing is not possible.

i just did clean some snow outside, hm
actually there is no other explanation except XILINX TOOL messup, that
is, the FIFO clocks
are constrained, no violation reported, but tools generate non-working
design.

i will still test the non-xilinx fifo properly for good luck test, but
then its time to redesign
to 8b-32b DPRAM it would have much less logic in 125mhz domain, so
there could be
more hope. Actually first version of that module is ready, but it
needs change of other
HDL code, and change of firmware, so working fifo would be less work
to, well if
fifo would work

thanks for all suggestion, i will continue with testing, and focusing
on timing-hunt
or then remove all fifo from that place

Antti








Article: 144683
Subject: Re: Please help, Xilinx FIFO problem!
From: John McCaskill <jhmccaskill@gmail.com>
Date: Tue, 22 Dec 2009 10:22:35 -0800 (PST)
Links: << >>  << T >>  << A >>
On Dec 22, 11:32=A0am, Antti <antti.luk...@googlemail.com> wrote:
> snip
>
>
>
> > > Antti
>
> > Since your change did not change the functionality of what you tested,
> > but changed the timing due to going through place and route again,
> > this sure sounds like it could be a timing problem to me.
>
> > I am sure that you have already checked that static path analysis
> > stated that all of your constraints were met, so generate a custom
> > timing report and have it list the unconstrained paths.
>
> > If something that matters is unconstrained, you are susceptible to
> > strange behavior from the design. Since the symptoms are appearing at
> > a FIFO, I would pay special attention to signals crossing between the
> > clock domains. You mention that the FPGA is about 80% full. If you
> > meant 80% of LUTs and FFs, you are getting into the region that the
> > place and route tools are having to work hard to meet timing
> > constraints. If something is unconstrained, =A0it could be getting
> > really poor placement and timing with respect to what it really needs.
>
> > Regards,
>
> > John McCaskillwww.FasterTechnology.com
>
> not very encouranging, I have had really hard times with Actel devices

Not trying to be discouraging Antti, I think you can find and fix this
problem.


> where i have witnessed a simple shift register at low as dirt clean
> clock
> to stop shifting if FPGA utilization did go above say 93% of
> versatales.
> There was no violations, nothing did show up in post place and route
> simulation, just chip was dead. Later i did read about MANUAL
> insertion of "inverting" clock tree to adjust the timings. This was
> scary!
>


If you are using synchronous design techniques, and are treating the
clocks properly by keeping them on the clock networks and only using
the dedicated clocking resources to manipulate them, static path
analysis should make sure that there are either no problems with the
constraints being met no matter how full the chip is, or finding that
there are timing problems.

Where some of the hard to find problems creep in is unconstrained
paths that should be constrained, improperly constrained paths, such
as improper use of multi-cycle and false path constraints, and
improper handling of asynchronous signals and clock domain crossing.
Sometimes the tools can work against you if you are not careful.  If
you have two or three FFs in a series to synchronize a signal, you
don't want to let the tools replicate those registers.


> current design utilization is
> Slices 14K 73%
> brams 116 80%
> DSP 39 80%
> GT11 6 50%
>

Ok, I thought you meant that LUT or FF utilization was at 80%, if it
is not LUTs and FFs that are at 80%, but the BRAMS and DSP blocks that
should not be a problem. Since slices are only at 73%, you have plenty
of LUTs and FFs left and the tools have lots of flexibility to work
with.  By default, the mapper will not put unrelated logic into the
same slice, so it tends to spread it out to give place and route
flexibility.  I have many designs that are at 99% slice utilization
well before I am finished adding stuff to them that place and route
just fine.


> the device is slowest speed grade FX40
> and there is not a single assembled with higher speed grade, so that
> testing is not possible.


If you are having clock domain crossing problems, a faster speed grade
may move the problem around, but is not the real solution.


>
> i just did clean some snow outside, hm
> actually there is no other explanation except XILINX TOOL messup, that
> is, the FIFO clocks
> are constrained, no violation reported, but tools generate non-working
> design.


Hope it is not the tools, that is hard to fix on your own!  I think
there are plenty of other possibilities.  This sounds like a timing
issue to me from what you have described.  You can find it with the
tools you have, it is just one of the more frustrating problems to
deal with.

Look at the unconstrained paths? What do you see?

I don't think the FIFO is the cause of the problem, but it is where it
shows up so put multiple ChipScope ILAs on it to cover the different
clock domains.  While not perfect, you can run the ILAs off of a clock
that is a multiple of the clock domain it is sampling to get some
timing info if you want. Something is going to look wrong here, follow
the trail.  Using the ILA tool in the FPGA editor you should be able
to change which signals the ILA is monitoring and get a new bitstream
to download in a matter of a few minutes since that does not require
you to go through place and route again.  I was doing this the last
few days to see why something that was working in simulation was not
working on the hardware, it is a powerful technique.


>
> i will still test the non-xilinx fifo properly for good luck test, but
> then its time to redesign
> to 8b-32b DPRAM it would have much less logic in 125mhz domain, so
> there could be
> more hope. Actually first version of that module is ready, but it
> needs change of other
> HDL code, and change of firmware, so working fifo would be less work
> to, well if
> fifo would work
>
> thanks for all suggestion, i will continue with testing, and focusing
> on timing-hunt
> or then remove all fifo from that place
>
> Antti



Good luck,

John McCaskill
www.FasterTechnology.com

Article: 144684
Subject: Re: Configuring the ML402
From: Griffin <captain.griffin@gmail.com>
Date: Tue, 22 Dec 2009 10:46:51 -0800 (PST)
Links: << >>  << T >>  << A >>
>   http://www.fpga4fun.com/ISEQuickStart.htmlgives a quick overview
> of the basic steps of loading code in to an FPGA using ISE (as I think the
> ML402 is Xilinx, there is a version for Quartis on the site as well if I'm
> wrong).
>         Its for an older version of ISE so the screen shots aren't quite
> correct but it gives the flow you need to compile and load a project which
> is I think what you are asking for. It got me to the point of being able to
> successfully compile, load and execute one of their example progams (writing
> my own is likely quite another matter though :-)) into their Dragon board
> using a later version of ISE.
>         At the end of it there is a reference to Xilinx tutorials for the
> various versions of ISE (I haven't gotten that far yet though :-))
>
> Peter Van Epp


Thanks, Peter.

Over the past couple months, I've succeeded in working with ISE VHDL-
only projects, but now I've moved onto my first embedded design and am
using only EDK. It is my understanding that when working with embedded
processor projects, running it on an FPGA (in my case, the Virtex-4 on
the ML402) is not as simple as downloading the bitstream (as is my
experience with working with vhdl projects on a Xilinx Spartan3
board) . If I understand correctly, there are executables (ELF?) and
such which must also be loaded to memory (DDR, SRAM) and then executed
such that the project runs. It is these two things that I am unsure
how to do. If I understand correctly, EDK11 can handle the bitstream
downloading via Device Configuration -> Download Bitstream, but what's
the deal with loading things into memory and executing them?

Can anyone point me to some good references on this subject?

Thanks!

-Sean.

Article: 144685
Subject: Re: Configuring the ML402
From: austin <austin@xilinx.com>
Date: Tue, 22 Dec 2009 11:06:42 -0800 (PST)
Links: << >>  << T >>  << A >>
Sean,

You can see how this is done on the latest V5 or V6 EDK projects, it
is the same.

There is a "download" software tool button, as well, if the code is in
the external SRAM or DDR memories.  The JTAG cable will download a
shell tool, so you can copy the .elf file into the memory location
needed, and then control the processor (start, stop, etc.).

http://www.xilinx.com/products/boards/ml505/ml505_11.1_1/docs/ml505_bsb_design_creation.pdf

slide 39, onwards, applies to the older boards and tools as well.

The location of the pulldown menus might be different in the older
versions, but it still works the same way (for .elf file loading).

Austin

Article: 144686
Subject: multiprocessor architecture
From: "ines_fr" <benhlima_ines@yahoo.fr>
Date: Tue, 22 Dec 2009 13:25:00 -0600
Links: << >>  << T >>  << A >>
Hello,

I use spartan 3 starter kit to make two cores processors. So,  can I put
the two cores processors   on the same PLB bus  or not? and if it is
possible, what
is the best method to working with : using two PLB buses for each core
processor  or a single PLB bus for both??

thanks in advance.

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

Article: 144687
Subject: Re: Configuring the ML402
From: Griffin <captain.griffin@gmail.com>
Date: Tue, 22 Dec 2009 12:28:32 -0800 (PST)
Links: << >>  << T >>  << A >>
Thanks, Austin, this was exactly what I needed.

-Sean.



> Sean,
>
> You can see how this is done on the latest V5 or V6 EDK projects, it
> is the same.
>
> There is a "download" software tool button, as well, if the code is in
> the external SRAM or DDR memories. =A0The JTAG cable will download a
> shell tool, so you can copy the .elf file into the memory location
> needed, and then control the processor (start, stop, etc.).
>
> http://www.xilinx.com/products/boards/ml505/ml505_11.1_1/docs/ml505_b...
>
> slide 39, onwards, applies to the older boards and tools as well.
>
> The location of the pulldown menus might be different in the older
> versions, but it still works the same way (for .elf file loading).
>
> Austin


Article: 144688
Subject: Re: Please help, Xilinx FIFO problem!
From: GLOW <glen.h.lowe@gmail.com>
Date: Wed, 23 Dec 2009 03:28:05 -0800 (PST)
Links: << >>  << T >>  << A >>

Antti,

Based on all the symptoms you have described, namely the read side of
the fifo going crazy and getting stale or duplicated data strongly
suggests that the problem is in the recovered clock.

I once worked on a chip where the duty cycle of the recovered clock
can vary widely and that the recovered clock even occasionally have a
stretched cycle where the clock looked like it was missing a cycle.
This was on an actual asic as opposed to an fpga. But the bottom line
was that we had unintentionally assumed that the recovered clock would
always be 50/50 duty cycle and that the recovered clock would never do
strange things like skip a clock.

If at all possible, I suggest you try the following.

1) I assume that you are using the recovered clock directly. If you
are, try running the clock thru an onboard PLL and use the pll
generated clock instead. If this helps your problem then do #2 below.

2) Route the recovered clock back out to a pin and observe it on a
1GHz scope. Configure the scope to trigger on anything less than 40/60
duty cycle.

Good Luck....

Article: 144689
Subject: Re: domain crossing and clock synchronisation for a high frequency
From: Angus <angusdundee@googlemail.com>
Date: Wed, 23 Dec 2009 04:54:18 -0800 (PST)
Links: << >>  << T >>  << A >>

I can't understand your answer given below. why did you opt for an
asynchronous
counter and how will you be able to set all the delays [1s, 10us]
whith a
synthesizer? actually what all the number stand for?

Cheers
>
> One of the best high-frequency counters I've done in an FPGA was a
> ripple counter. =A0Unlike a synchronous counter, a ripple counter only
> has a single point of entry that you need to gate, and so is safe for
> any asynchronous input signal up to hundreds of MHz.
>
> I wrapped a synchronous state machine around it that:
> =A0 1) clock enables the first flip-flop in the counter
> =A0 2) waits 1 second
> =A0 3) deasserts the clock enable
> =A0 4) waits 10 us for the ripple counter to settle out
> =A0 5) registers the now static outputs back into the clocked domain
> =A0 6) goto 1
>
> The only problem is that you don't know for certain how long it will
> take the ripple counter to settle out, but if you're willing to go way,
> way overboard on that dead time then everything works like a dream.
>
> --
> Rob Gaddi, Highland Technology
> Email address is currently out of order- Hide quoted text -
>
> - Show quoted text -


Article: 144690
Subject: Re: Strange behavior with serial ADC chip select and MISO pin
From: Nicholas Kinar <n.kinar@usask.ca>
Date: Wed, 23 Dec 2009 09:02:09 -0600
Links: << >>  << T >>  << A >>

> 
> What is really weird is that according to SignalTap II, the MISO of the 
> 6th ADC does not want to go high after startup.  All of the other MISO 
> outputs of the ADCs go high after startup.  The signal is represented as 
> MISO[5] in the Quartus II pin planner, and is an input in the associated 
> Verilog code.  Moreover, SignalTap II tells me that the chip select #CS 
> output of the 6th ADC is high.  Using Verilog code, I have attempted to 
> toggle the #CS of all ADCs.  Doing so causes all MISO outputs of the 
> ADCs to drop low (when #CS is low), and then to go high again (when #CS 
> is high).  However, according to the SignalTap II logic analyzer, 
> MISO[5] remains at logic low.
> 

Even more bizarre is that the problem seems to take care of itself after 
  the FPGA reads data from the ADCs.  Apparently after the ADCs are 
triggered, MISO goes high, and then drops low again just in time for the 
data to be read from each ADC.

Nicholas

Article: 144691
Subject: Re: H.264 on Spartan3A DSP
From: Nicholas Kinar <n.kinar@usask.ca>
Date: Wed, 23 Dec 2009 09:39:34 -0600
Links: << >>  << T >>  << A >>
Guru wrote:
> Hi all,
> 
> I am building a new megapixel camera based on Spartan3A DSP 3400. For
> one of the applications I would need H.264 core with a performance of
> minimal 66Mpix/s. I prefer EDK HW core since the camera "brain" is
> composed there.
> Does anyone has anything to recommend?
> 
> Best regards,
> 
> Ales


Perhaps the following FOSS project from SourceForge would be of interest?

http://hardh264.sourceforge.net/
http://www.drtonygeorge.com/Video/h264/h264_rtl.htm

Apparently the hardh264 core is written in VHDL.  You will have to 
evaluate this  IP to see if it suits your application with respect to 
performance.  Sometimes purchasing IP is necessary for an application, 
but perhaps this IP may be more than good enough for your own project. 
As alawys, be sure to check the licensing of all IP that you either 
download or purchase.

Article: 144692
Subject: Re: Strange behavior with serial ADC chip select and MISO pin
From: Nicholas Kinar <n.kinar@usask.ca>
Date: Wed, 23 Dec 2009 10:54:10 -0600
Links: << >>  << T >>  << A >>

> Even more bizarre is that the problem seems to take care of itself after 
>  the FPGA reads data from the ADCs.  Apparently after the ADCs are 
> triggered, MISO goes high, and then drops low again just in time for the 
> data to be read from each ADC.
> 

Strange but true: it appears that CS[5], which is the chip-select of the 
6th ADC, was never being assigned in the Quartus II pin-planner.  Oddly 
  enough, the pin planner showed that the pin was indeed being assigned. 
  Could this be a bug in the pin planner?  I don't know.  However, it 
now appears that the problem is gone, and all of the MISO pins go high 
on startup.

Nicholas

Article: 144693
Subject: Re: Trouble with Xilinx DCM - Spartan3
From: ghelbig <ghelbig@lycos.com>
Date: Wed, 23 Dec 2009 10:40:46 -0800 (PST)
Links: << >>  << T >>  << A >>
On Dec 20, 12:11=A0pm, Patrick Maupin <pmau...@gmail.com> wrote:
> On Dec 20, 8:43=A0am, emeb <ebromba...@gmail.com> wrote:
>
>
>
> > On Dec 19, 10:25=A0am, ghelbig <ghel...@lycos.com> wrote:
>
> > > Details I should have included:
>
> > > The external clock is a synthesizer that defaults to 50MHz. =A0After
> > > initialization, it is changed to 100MHz. =A0The DCM is used to reduce
> > > the skew between the internal clock and the external clock and create
> > > a half-speed clock for some of the logic.
>
> > > Some percentage of the time, the chip "just don't run"; my current
> > > theory is that the clock comes up strange.
>
> > > I'm not getting anything useful from the status lines. =A0At the time
> > > the frequency is changed, I get a pulse on status[1]; after that, the=
y
> > > are always low. =A0I've waited "forever", and the locked signal never
> > > goes true.
>
> > > Thanks!
>
> > Another suggestion, probably as helpful as "is it plugged in?" - make
> > sure that the logic which generates your DCM reset isn't being clocked
> > by that DCM. I facepalmed this once...
>
> > Eric
>
> Yeah, that's an excellent idea. =A0Especially in a complicated design,
> reset loops are easy to achieve...
>
> Pat

I think I found a solution.

The external clock is spec'd at 150 fS (150 femptoseconds) of jitter,
so I didn't go there.

The status lines are near useless; observed behavior does not match
their description.  No amount of futzing with reset would make it
behave as documented.

I am switching the synthesizer from 50MHz to 100MHz after
initialization.  According to the data sheet, either the low range
(18~167 MHz) or the high range (48~280 MHz) should be "just fine".

In practice, the high range works (the DCM regains lock), and the low
range does not.

Live and learn.

Article: 144694
Subject: Re: Controlling the I2C master from Opencores.org
From: "Brad Smallridge" <bradsmallridge@dslextreme.com>
Date: Wed, 23 Dec 2009 14:07:07 -0800
Links: << >>  << T >>  << A >>
> Hi,
> Thanks a lot for the code. However, this seems more like a replacement for
> the opencores.org I2C master core!

Might be. But I didn't look at opencores.

> I was wanting to use this core since it supports all the
> 'harder-to-support' I2C specifications and it has been debugged for quite 
> a
> while now. The only problem is that it only brings things up to the 'byte'
> level. There still needs to be a fair level of handshaking and pooling in
> order to generate a transfer of the type'write ABCD at address 08'.

You would simply put this in your data array:

START,h08,ACK,hAB,ACK,hCD,ACK,STOP,

Not sure what else you need. You don't say.

Brad Smallridge
Ai Vision



Article: 144695
Subject: Re: Strange behavior with serial ADC chip select and MISO pin
From: Thomas Stanka <usenet_nospam_valid@stanka-web.de>
Date: Wed, 23 Dec 2009 23:30:30 -0800 (PST)
Links: << >>  << T >>  << A >>
On 22 Dez., 16:03, Nicholas Kinar <n.ki...@usask.ca> wrote:
> -------
> Warning: Can't achieve timing requirement Clock Setup:
> 'my_pll:pll|altpll:altpll_component|_clk0' along 166 path(s). See Report
> window for details.
>
> Warning: Can't achieve timing requirement Clock Setup: 'clk' along 95
> path(s). See Report window for details.
>
> Warning: Circuit may not operate. Detected 76 non-operational path(s)
> clocked by clock "altera_internal_jtag~TCKUTAP" with clock skew larger
> than data delay. See Compilation Report for details.
> -------
>
> I suspect that these warnings may indicate that there is a problem with
> the timing analysis.

Your suspection is almost right. As you already found the problem on
the pin, I suggest to get rid of these Warnings before they bite you
next.
If the timing requirement could not be achieved, you are not
guaranteed, that your design will always work in the intended way, as
in some situations your data will need longer to be correct than your
clock signal allows, which means your clock will sample wrong data.
It may be possible, that the slack is so small, that you will
experience this only on some devices or on some temperatures, a large
slack might affect every device on every temperature, but due to the
nature of the path it may be undetected for longer time, until you set
the device in the condition, when this long path is sensible.

A typical long path in an adder through the carry. This adder will
have no problem for pairs of input numbers that didn't stress the
carry (e.g. 0 and n, 1+4,...). If you want to add two numbers that
stress carry you will see that some bits have the correct value and
other the wrong value, leading to complete strange results.

bye Thomas


Article: 144696
Subject: Altera FPGA configuration using JTAG
From: "gopal_amlekar" <gopal_amlekar@yahoo.com>
Date: Thu, 24 Dec 2009 09:00:00 -0600
Links: << >>  << T >>  << A >>
Hello,

I want to configure an FPGA (Altera Cyclone II) using JTAG programming
method via USB. I have done a design using a PIC18F2550 and succedded in
configuring Xilinx FPGA. I want to do the same thing fo Altera devices.

Has anybody done that previously? The point where I am stuck is, I don't
know the internal file formats of Altera files (e.g. rbf or sof files etc.)
 I need information about header and other details in the altera file. So I
can skip them and transmit only the configuration data on JTAG to the
FPGA.

Specifically, if anyone can guide me about the file formats of Altera, I
will be thankful.

Thanking in advance..
Regards,
Gopal Amlekar




Article: 144697
Subject: Re: Altera FPGA configuration using JTAG
From: Rob <nothear@nowhere.com>
Date: Thu, 24 Dec 2009 10:39:33 -0500
Links: << >>  << T >>  << A >>
You might be better off using the PIC (or whatever mirco/processor) 
implement the serial programming.  This method is well documented and 
very straightforward to implement.  I'm not sure Altera publishes 
anything allowing you to configure using JTAG, other than their 
proprietary ByteBlaster, etc.



gopal_amlekar wrote:
> Hello,
> 
> I want to configure an FPGA (Altera Cyclone II) using JTAG programming
> method via USB. I have done a design using a PIC18F2550 and succedded in
> configuring Xilinx FPGA. I want to do the same thing fo Altera devices.
> 
> Has anybody done that previously? The point where I am stuck is, I don't
> know the internal file formats of Altera files (e.g. rbf or sof files etc.)
>  I need information about header and other details in the altera file. So I
> can skip them and transmit only the configuration data on JTAG to the
> FPGA.
> 
> Specifically, if anyone can guide me about the file formats of Altera, I
> will be thankful.
> 
> Thanking in advance..
> Regards,
> Gopal Amlekar
> 
> 
> 

Article: 144698
Subject: Re: Problem with Xilinx ISE and Spartan3
From: Angus <angusdundee@googlemail.com>
Date: Thu, 24 Dec 2009 09:25:03 -0800 (PST)
Links: << >>  << T >>  << A >>
On 4 Dec, 10:30, Mathias Weierganz <mwe...@expires-31-12-2009.news-
group.org> wrote:
> As a beginner in FPGA design I run to the following problem:
> I want to generate a 200MHz clock by the DCM from 2 different
> clock sources, one is a 10MHz clock, the other is 60MHz.
> My idea was to divide the 60MHz by 6 and alternatively
> switch between the both clock-signals.
>

> Mathias

I am slightly confused with your suggestion. To generate a 200mhz
clock signal from a 10 (or 60) mhz clock input, you have just to set
the DCM frequency multiplication to 20(or 20/6). Am I mistaken?

Article: 144699
Subject: Re: Problem with Xilinx ISE and Spartan3
From: Gabor <gabor@alacron.com>
Date: Thu, 24 Dec 2009 14:47:48 -0800 (PST)
Links: << >>  << T >>  << A >>
On Dec 24, 12:25=A0pm, Angus <angusdun...@googlemail.com> wrote:
> On 4 Dec, 10:30, Mathias Weierganz <mwe...@expires-31-12-2009.news-
>
> group.org> wrote:
> > As a beginner in FPGA design I run to the following problem:
> > I want to generate a 200MHz clock by the DCM from 2 different
> > clock sources, one is a 10MHz clock, the other is 60MHz.
> > My idea was to divide the 60MHz by 6 and alternatively
> > switch between the both clock-signals.
>
> > Mathias
>
> I am slightly confused with your suggestion. To generate a 200mhz
> clock signal from a 10 (or 60) mhz clock input, you have just to set
> the DCM frequency multiplication to 20(or 20/6). Am I mistaken?

The issue would be switching clock sources on the fly.  The DCM
at least before Virtex 5 was completely programmed by the bitstream,
so you couldn't change the multiplication / division factors without
at least a partial reconfiguration.  So the idea of creating the same
input frequency from two sources seems sound.  What you might lose
is any constant phase relationship to the input clocks.  However if
this is just a frequency synthesis problem that shouldn't matter.
There's no reason not to use a fabric signal to feed the DCM if
you don't need that phase relationship back to the input source.
I suppose the original idea was to allow two sources so the 200 MHz
would be available even if only one of the two clocks is running.

One note of caution, if you have two clocks and want to switch
between them using a BUFGMUX, then you should be aware
that the glitch prevention circuitry can prevent the switch
from occurring if one of the clocks is not running.  So it may be
better to use a fabric-based mux followed by a simple BUFG.

Regards,
Gabor



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