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 136875

Article: 136875
Subject: Looking for FPGA engineer for HD camera project
From: ooze3d@gmail.com
Date: Wed, 10 Dec 2008 09:04:41 -0800 (PST)
Links: << >>  << T >>  << A >>
Hi all,

   I'm working on a project to create a basic FPGA based digital
cinema camera. The FPGA would have to capture a 1920x1080 progressive
frames at speeds from 1 to 60 frames/second from a Kodak CCD we've
already chosen, convert the stream to a DNG sequence (separate Adobe
DNG files, you can find the SDK at www.adobe.com) and store them in an
internal SATA SSD disk.

   The FPGA also needs to control every single feature in the sensor
with a basic user interface, enable a DVI out for monitoring and a USB
in/out so the files can be downloaded to a computer.

   This is of course a paid job.

Article: 136876
Subject: Re: Sampling a clock
From: KJ <kkjennings@sbcglobal.net>
Date: Wed, 10 Dec 2008 09:14:41 -0800 (PST)
Links: << >>  << T >>  << A >>
On Dec 10, 11:43=A0am, Rob <robns...@frontiernet.net> wrote:

>
> There are no asynchronous inputs. =A0All the inputs are sync'd to the
> incoming slow 6kHz clock. =A0The other fast internal FPGA MHz clock is
> for something completely unrelated and has nothing to do with the SM.
>
> Rob- Hide quoted text -
>

Maybe add a free running counter that is clocked by the 6kHz clock
that counts from 0 to 24 and then goes back to 0 resetting it only
during powerup.  Bring the counter out to debug pins.  If your
original hypothesis is correct that "...there is a spurious edge which
my SM reacts to, thus causing erroneous data to be latched." then this
counter would at some point end up at a non-zero count between
transmissions (I'm assuming here that the transmissions are not
continuous and there are identifiable gaps in time during which the
state machine is waiting for the next 25 clock transmission to
occur).  With that setup you can also look for times when the counter
changes states quicker than the expected 6 kHz rate.  It can be a tad
difficult depending on what equipment you can bring to bear and how
many debug pins you have in your FPGA, but at least it gives you a
direct view of flops inside the device that are being clocked and that
will change state with every clock.

Building somewhat further on that approach, if the state machine
already has a signal that identifies the 'waiting for a new
transmission to occur' time, then you could gate that signal with the
counter being 0 and simply output a '1' when the protocol has been
broken.  That gives you one specific signal to monitor to trigger the
scope.

Either of those approaches though is only meant to give you a known
reliable trigger mechanism for a scope or logic analyzer so you can
investigate further (if it triggers) or reject your hypothesis (if it
does not).

It's also not really clear whether you have such a trigger condition
or if you're relying on perhaps some higher level system observation
instead.  Your original thought to build a pulse monitor was somewhat
along these lines, the problem with that approach though is that
you're jumping to a solution that has holes to it.  Even if your
hypothesis is correct you haven't actually verified the root cause
problem.

Kevin Jennings

Article: 136877
Subject: Re: Looking for FPGA engineer for HD camera project
From: LittleAlex <alex.louie@email.com>
Date: Wed, 10 Dec 2008 09:26:13 -0800 (PST)
Links: << >>  << T >>  << A >>
On Dec 10, 10:04 am, ooz...@gmail.com wrote:
> Hi all,
>
>    I'm working on a project to create a basic FPGA based digital
> cinema camera. The FPGA would have to capture a 1920x1080 progressive
> frames at speeds from 1 to 60 frames/second from a Kodak CCD we've
> already chosen, convert the stream to a DNG sequence (separate Adobe
> DNG files, you can find the SDK atwww.adobe.com) and store them in an
> internal SATA SSD disk.
>
>    The FPGA also needs to control every single feature in the sensor
> with a basic user interface, enable a DVI out for monitoring and a USB
> in/out so the files can be downloaded to a computer.
>
>    This is of course a paid job.

1) You didn't say where the work will be done.  USENET is global,
remember?
2) This of course is NOT a job posting board.

Article: 136878
Subject: Re: Sampling a clock
From: Rob <robnstef@frontiernet.net>
Date: Wed, 10 Dec 2008 10:05:49 -0800 (PST)
Links: << >>  << T >>  << A >>
On Dec 10, 12:14=A0pm, KJ <kkjenni...@sbcglobal.net> wrote:
> On Dec 10, 11:43=A0am, Rob <robns...@frontiernet.net> wrote:
>
>
>
> > There are no asynchronous inputs. =A0All the inputs are sync'd to the
> > incoming slow 6kHz clock. =A0The other fast internal FPGA MHz clock is
> > for something completely unrelated and has nothing to do with the SM.
>
> > Rob- Hide quoted text -
>
> Maybe add a free running counter that is clocked by the 6kHz clock
> that counts from 0 to 24 and then goes back to 0 resetting it only
> during powerup. =A0Bring the counter out to debug pins. =A0If your
> original hypothesis is correct that "...there is a spurious edge which
> my SM reacts to, thus causing erroneous data to be latched." then this
> counter would at some point end up at a non-zero count between
> transmissions (I'm assuming here that the transmissions are not
> continuous and there are identifiable gaps in time during which the
> state machine is waiting for the next 25 clock transmission to
> occur). =A0With that setup you can also look for times when the counter
> changes states quicker than the expected 6 kHz rate. =A0It can be a tad
> difficult depending on what equipment you can bring to bear and how
> many debug pins you have in your FPGA, but at least it gives you a
> direct view of flops inside the device that are being clocked and that
> will change state with every clock.

I already have a counter (that counts from 0 to 24) tied to the
incoming 6kHz clock. It is this counter that determines where I am in
the serial stream; and thus determines which flop within my data
register gets clocked with the incoming data.  But yes, I have already
thought about doing this.  But I don't need to--read below.


>
> Building somewhat further on that approach, if the state machine
> already has a signal that identifies the 'waiting for a new
> transmission to occur' time, then you could gate that signal with the
> counter being 0 and simply output a '1' when the protocol has been
> broken. =A0That gives you one specific signal to monitor to trigger the
> scope.
>
> Either of those approaches though is only meant to give you a known
> reliable trigger mechanism for a scope or logic analyzer so you can
> investigate further (if it triggers) or reject your hypothesis (if it
> does not).
>
> It's also not really clear whether you have such a trigger condition
> or if you're relying on perhaps some higher level system observation
> instead. =A0Your original thought to build a pulse monitor was somewhat
> along these lines, the problem with that approach though is that
> you're jumping to a solution that has holes to it. =A0Even if your
> hypothesis is correct you haven't actually verified the root cause
> problem.
>

I did build the pulse monitor and the problem got worse.  This of
course told me that I must be fighting a timing that is on the hairy
edge, as there is a slight delay through my "filter".  So I started
looking at the path in much more scrutiny and found a section of the
placement that didn't have a lot of margin.  I tightened this up and
the problems have disappeared.  This obviously makes more sense since
I never saw any glitches/runts on the scope.  And it also explains why
some boards worked and some didn't.

Again, I appreciate the dialogue....



Article: 136879
Subject: Re: Sampling a clock
From: bsp0524@gmail.com
Date: Wed, 10 Dec 2008 11:04:09 -0800 (PST)
Links: << >>  << T >>  << A >>
Instead of complicated state machine to detect glitches or runt pulse,
one can simply use the clock signal to toggle a T-flipflop. If you
observer a pulse of shorter duration than expected then there is a
glitch or a runt pulse.

Use the 6Kz clock and divide it by 2 using a flipflop. Put no other
loads on this clock like other than single flipflop.
Bring out the divided clock to the output pin and observe on the
scope.
Set the trigger to trigger on any pulse less than time period of  the
3KHz expected signal.
If you get a pulse of shorter time period then you have a glitch or
runt pulse.

If the device has DDR registers than they would be ideal and you can
get 6kHz output instead of 3 KHz.

Brijesh





On Dec 10, 1:05=A0pm, Rob <robns...@frontiernet.net> wrote:
> On Dec 10, 12:14=A0pm, KJ <kkjenni...@sbcglobal.net> wrote:
>
>
>
> > On Dec 10, 11:43=A0am, Rob <robns...@frontiernet.net> wrote:
>
> > > There are no asynchronous inputs. =A0All the inputs are sync'd to the
> > > incoming slow 6kHz clock. =A0The other fast internal FPGA MHz clock i=
s
> > > for something completely unrelated and has nothing to do with the SM.
>
> > > Rob- Hide quoted text -
>
> > Maybe add a free running counter that is clocked by the 6kHz clock
> > that counts from 0 to 24 and then goes back to 0 resetting it only
> > during powerup. =A0Bring the counter out to debug pins. =A0If your
> > original hypothesis is correct that "...there is a spurious edge which
> > my SM reacts to, thus causing erroneous data to be latched." then this
> > counter would at some point end up at a non-zero count between
> > transmissions (I'm assuming here that the transmissions are not
> > continuous and there are identifiable gaps in time during which the
> > state machine is waiting for the next 25 clock transmission to
> > occur). =A0With that setup you can also look for times when the counter
> > changes states quicker than the expected 6 kHz rate. =A0It can be a tad
> > difficult depending on what equipment you can bring to bear and how
> > many debug pins you have in your FPGA, but at least it gives you a
> > direct view of flops inside the device that are being clocked and that
> > will change state with every clock.
>
> I already have a counter (that counts from 0 to 24) tied to the
> incoming 6kHz clock. It is this counter that determines where I am in
> the serial stream; and thus determines which flop within my data
> register gets clocked with the incoming data. =A0But yes, I have already
> thought about doing this. =A0But I don't need to--read below.
>
>
>
>
>
> > Building somewhat further on that approach, if the state machine
> > already has a signal that identifies the 'waiting for a new
> > transmission to occur' time, then you could gate that signal with the
> > counter being 0 and simply output a '1' when the protocol has been
> > broken. =A0That gives you one specific signal to monitor to trigger the
> > scope.
>
> > Either of those approaches though is only meant to give you a known
> > reliable trigger mechanism for a scope or logic analyzer so you can
> > investigate further (if it triggers) or reject your hypothesis (if it
> > does not).
>
> > It's also not really clear whether you have such a trigger condition
> > or if you're relying on perhaps some higher level system observation
> > instead. =A0Your original thought to build a pulse monitor was somewhat
> > along these lines, the problem with that approach though is that
> > you're jumping to a solution that has holes to it. =A0Even if your
> > hypothesis is correct you haven't actually verified the root cause
> > problem.
>
> I did build the pulse monitor and the problem got worse. =A0This of
> course told me that I must be fighting a timing that is on the hairy
> edge, as there is a slight delay through my "filter". =A0So I started
> looking at the path in much more scrutiny and found a section of the
> placement that didn't have a lot of margin. =A0I tightened this up and
> the problems have disappeared. =A0This obviously makes more sense since
> I never saw any glitches/runts on the scope. =A0And it also explains why
> some boards worked and some didn't.
>
> Again, I appreciate the dialogue....


Article: 136880
Subject: Re: Sampling a clock
From: doug <xx@xx.com>
Date: Wed, 10 Dec 2008 11:13:52 -0800
Links: << >>  << T >>  << A >>


Rob wrote:

> On Dec 10, 12:14 pm, KJ <kkjenni...@sbcglobal.net> wrote:
> 
>>On Dec 10, 11:43 am, Rob <robns...@frontiernet.net> wrote:
>>
>>
>>
>>
>>>There are no asynchronous inputs.  All the inputs are sync'd to the
>>>incoming slow 6kHz clock.  The other fast internal FPGA MHz clock is
>>>for something completely unrelated and has nothing to do with the SM.
>>
>>>Rob- Hide quoted text -
>>
>>Maybe add a free running counter that is clocked by the 6kHz clock
>>that counts from 0 to 24 and then goes back to 0 resetting it only
>>during powerup.  Bring the counter out to debug pins.  If your
>>original hypothesis is correct that "...there is a spurious edge which
>>my SM reacts to, thus causing erroneous data to be latched." then this
>>counter would at some point end up at a non-zero count between
>>transmissions (I'm assuming here that the transmissions are not
>>continuous and there are identifiable gaps in time during which the
>>state machine is waiting for the next 25 clock transmission to
>>occur).  With that setup you can also look for times when the counter
>>changes states quicker than the expected 6 kHz rate.  It can be a tad
>>difficult depending on what equipment you can bring to bear and how
>>many debug pins you have in your FPGA, but at least it gives you a
>>direct view of flops inside the device that are being clocked and that
>>will change state with every clock.
> 
> 
> I already have a counter (that counts from 0 to 24) tied to the
> incoming 6kHz clock. It is this counter that determines where I am in
> the serial stream; and thus determines which flop within my data
> register gets clocked with the incoming data.  But yes, I have already
> thought about doing this.  But I don't need to--read below.
> 
> 
> 
>>Building somewhat further on that approach, if the state machine
>>already has a signal that identifies the 'waiting for a new
>>transmission to occur' time, then you could gate that signal with the
>>counter being 0 and simply output a '1' when the protocol has been
>>broken.  That gives you one specific signal to monitor to trigger the
>>scope.
>>
>>Either of those approaches though is only meant to give you a known
>>reliable trigger mechanism for a scope or logic analyzer so you can
>>investigate further (if it triggers) or reject your hypothesis (if it
>>does not).
>>
>>It's also not really clear whether you have such a trigger condition
>>or if you're relying on perhaps some higher level system observation
>>instead.  Your original thought to build a pulse monitor was somewhat
>>along these lines, the problem with that approach though is that
>>you're jumping to a solution that has holes to it.  Even if your
>>hypothesis is correct you haven't actually verified the root cause
>>problem.
>>
> 
> 
> I did build the pulse monitor and the problem got worse.  This of
> course told me that I must be fighting a timing that is on the hairy
> edge, as there is a slight delay through my "filter".  So I started
> looking at the path in much more scrutiny and found a section of the
> placement that didn't have a lot of margin.  I tightened this up and
> the problems have disappeared.  This obviously makes more sense since
> I never saw any glitches/runts on the scope.  And it also explains why
> some boards worked and some didn't.
> 
> Again, I appreciate the dialogue....
> 
> 
If this is an issue of the relative timing of the clock and data
as you note above, why not just take the data on the other edge
of the clock where it is stable and there are no timing issues
at all?

Article: 136881
Subject: Re: Sampling a clock
From: Rob <robnstef@frontiernet.net>
Date: Wed, 10 Dec 2008 13:12:16 -0800 (PST)
Links: << >>  << T >>  << A >>
On Dec 10, 2:13=A0pm, doug <x...@xx.com> wrote:
> Rob wrote:
> > On Dec 10, 12:14 pm, KJ <kkjenni...@sbcglobal.net> wrote:
>
> >>On Dec 10, 11:43 am, Rob <robns...@frontiernet.net> wrote:
>
> >>>There are no asynchronous inputs. =A0All the inputs are sync'd to the
> >>>incoming slow 6kHz clock. =A0The other fast internal FPGA MHz clock is
> >>>for something completely unrelated and has nothing to do with the SM.
>
> >>>Rob- Hide quoted text -
>
> >>Maybe add a free running counter that is clocked by the 6kHz clock
> >>that counts from 0 to 24 and then goes back to 0 resetting it only
> >>during powerup. =A0Bring the counter out to debug pins. =A0If your
> >>original hypothesis is correct that "...there is a spurious edge which
> >>my SM reacts to, thus causing erroneous data to be latched." then this
> >>counter would at some point end up at a non-zero count between
> >>transmissions (I'm assuming here that the transmissions are not
> >>continuous and there are identifiable gaps in time during which the
> >>state machine is waiting for the next 25 clock transmission to
> >>occur). =A0With that setup you can also look for times when the counter
> >>changes states quicker than the expected 6 kHz rate. =A0It can be a tad
> >>difficult depending on what equipment you can bring to bear and how
> >>many debug pins you have in your FPGA, but at least it gives you a
> >>direct view of flops inside the device that are being clocked and that
> >>will change state with every clock.
>
> > I already have a counter (that counts from 0 to 24) tied to the
> > incoming 6kHz clock. It is this counter that determines where I am in
> > the serial stream; and thus determines which flop within my data
> > register gets clocked with the incoming data. =A0But yes, I have alread=
y
> > thought about doing this. =A0But I don't need to--read below.
>
> >>Building somewhat further on that approach, if the state machine
> >>already has a signal that identifies the 'waiting for a new
> >>transmission to occur' time, then you could gate that signal with the
> >>counter being 0 and simply output a '1' when the protocol has been
> >>broken. =A0That gives you one specific signal to monitor to trigger the
> >>scope.
>
> >>Either of those approaches though is only meant to give you a known
> >>reliable trigger mechanism for a scope or logic analyzer so you can
> >>investigate further (if it triggers) or reject your hypothesis (if it
> >>does not).
>
> >>It's also not really clear whether you have such a trigger condition
> >>or if you're relying on perhaps some higher level system observation
> >>instead. =A0Your original thought to build a pulse monitor was somewhat
> >>along these lines, the problem with that approach though is that
> >>you're jumping to a solution that has holes to it. =A0Even if your
> >>hypothesis is correct you haven't actually verified the root cause
> >>problem.
>
> > I did build the pulse monitor and the problem got worse. =A0This of
> > course told me that I must be fighting a timing that is on the hairy
> > edge, as there is a slight delay through my "filter". =A0So I started
> > looking at the path in much more scrutiny and found a section of the
> > placement that didn't have a lot of margin. =A0I tightened this up and
> > the problems have disappeared. =A0This obviously makes more sense since
> > I never saw any glitches/runts on the scope. =A0And it also explains wh=
y
> > some boards worked and some didn't.
>
> > Again, I appreciate the dialogue....
>
> If this is an issue of the relative timing of the clock and data
> as you note above, why not just take the data on the other edge
> of the clock where it is stable and there are no timing issues
> at all?

The master sends out the data on the falling edge so one would think
that since I'm using the rising edge of the clock that there would be
plenty of tsu time.

Article: 136882
Subject: Xilinx ISE 10.1 SP3 MPMC NPI VHDL simple sample needed
From: google@schwarzers.de
Date: Wed, 10 Dec 2008 14:39:05 -0800 (PST)
Links: << >>  << T >>  << A >>
Hello all,

as a newbe with FPGAs I have no clue how to use the NPI interface of
the MPMC from Xilinx.
I haven't found a really good example.
What I need is a simple module in VHDL which reads and writes the
memory (maybe a simple memory test).

Is there something available ??? Can someone help me out ?

Thanks a lot!

/HB

Article: 136883
Subject: Re: Sampling a clock
From: doug <xx@xx.com>
Date: Wed, 10 Dec 2008 14:58:39 -0800
Links: << >>  << T >>  << A >>


Rob wrote:
> On Dec 10, 2:13 pm, doug <x...@xx.com> wrote:
> 
>>Rob wrote:
>>
>>>On Dec 10, 12:14 pm, KJ <kkjenni...@sbcglobal.net> wrote:
>>
>>>>On Dec 10, 11:43 am, Rob <robns...@frontiernet.net> wrote:
>>
>>>>>There are no asynchronous inputs.  All the inputs are sync'd to the
>>>>>incoming slow 6kHz clock.  The other fast internal FPGA MHz clock is
>>>>>for something completely unrelated and has nothing to do with the SM.
>>
>>>>>Rob- Hide quoted text -
>>
>>>>Maybe add a free running counter that is clocked by the 6kHz clock
>>>>that counts from 0 to 24 and then goes back to 0 resetting it only
>>>>during powerup.  Bring the counter out to debug pins.  If your
>>>>original hypothesis is correct that "...there is a spurious edge which
>>>>my SM reacts to, thus causing erroneous data to be latched." then this
>>>>counter would at some point end up at a non-zero count between
>>>>transmissions (I'm assuming here that the transmissions are not
>>>>continuous and there are identifiable gaps in time during which the
>>>>state machine is waiting for the next 25 clock transmission to
>>>>occur).  With that setup you can also look for times when the counter
>>>>changes states quicker than the expected 6 kHz rate.  It can be a tad
>>>>difficult depending on what equipment you can bring to bear and how
>>>>many debug pins you have in your FPGA, but at least it gives you a
>>>>direct view of flops inside the device that are being clocked and that
>>>>will change state with every clock.
>>
>>>I already have a counter (that counts from 0 to 24) tied to the
>>>incoming 6kHz clock. It is this counter that determines where I am in
>>>the serial stream; and thus determines which flop within my data
>>>register gets clocked with the incoming data.  But yes, I have already
>>>thought about doing this.  But I don't need to--read below.
>>
>>>>Building somewhat further on that approach, if the state machine
>>>>already has a signal that identifies the 'waiting for a new
>>>>transmission to occur' time, then you could gate that signal with the
>>>>counter being 0 and simply output a '1' when the protocol has been
>>>>broken.  That gives you one specific signal to monitor to trigger the
>>>>scope.
>>
>>>>Either of those approaches though is only meant to give you a known
>>>>reliable trigger mechanism for a scope or logic analyzer so you can
>>>>investigate further (if it triggers) or reject your hypothesis (if it
>>>>does not).
>>
>>>>It's also not really clear whether you have such a trigger condition
>>>>or if you're relying on perhaps some higher level system observation
>>>>instead.  Your original thought to build a pulse monitor was somewhat
>>>>along these lines, the problem with that approach though is that
>>>>you're jumping to a solution that has holes to it.  Even if your
>>>>hypothesis is correct you haven't actually verified the root cause
>>>>problem.
>>
>>>I did build the pulse monitor and the problem got worse.  This of
>>>course told me that I must be fighting a timing that is on the hairy
>>>edge, as there is a slight delay through my "filter".  So I started
>>>looking at the path in much more scrutiny and found a section of the
>>>placement that didn't have a lot of margin.  I tightened this up and
>>>the problems have disappeared.  This obviously makes more sense since
>>>I never saw any glitches/runts on the scope.  And it also explains why
>>>some boards worked and some didn't.
>>
>>>Again, I appreciate the dialogue....
>>
>>If this is an issue of the relative timing of the clock and data
>>as you note above, why not just take the data on the other edge
>>of the clock where it is stable and there are no timing issues
>>at all?
> 
> 
> The master sends out the data on the falling edge so one would think
> that since I'm using the rising edge of the clock that there would be
> plenty of tsu time.

Are you feeding the clock signal into the fpga on a clock pin or
a data pin?  Any signals that go around on nonclock nets and
get used for clocks at some point are going to be trouble because
the skew will make shift registers very unpredictable.  What you
are describing sounds like that since you are taking the data
on the "good" side of the clock.  You could also use your internal
clock to make a latch and filter on the clock line and the rising edge
detection after the filter could enable a shift.

Article: 136884
Subject: Re: Looking for FPGA engineer for HD camera project
From: ooze3d@gmail.com
Date: Wed, 10 Dec 2008 16:07:36 -0800 (PST)
Links: << >>  << T >>  << A >>
I'm sorry. I didn't know I couldn't offer jobs here.

Besides that, the person who's interested would sign a contract and
receive the hardware needed by mail to work at home. That's why I
didn't say where.

Article: 136885
Subject: Adding 128Kx8 SRAM to Spartan 3E FPGA
From: mpthompson <mpthompson@gmail.com>
Date: Wed, 10 Dec 2008 18:26:37 -0800 (PST)
Links: << >>  << T >>  << A >>
On a Xilinx Spartan 3e FPGA, I'm attempting to use the XPS MCH EMC
memory controller to connect with an 128Kx8 SRAM chip (CY62128DV30LL)
using Xilinx 10.1 EDK.  If I attempt to specify the address bus as 17
bits in the MHS file I'll get the following error when generating the
bitstream:

-----------------------------------------------------------
ERROR:MDT - GLOBAL PORT:fpga_0_SRAM_A_pin CONNECTOR:fpga_0_SRAM_A -
   C:\Xilinx\Projects\dlp-fpga_project_5\system.mhs line 21 - 32 bit-
width
   connector assigned to 17 bit-width port
Completion time: 0.00 seconds
ERROR:MDT - platgen failed with errors!
-----------------------------------------------------------

If I specify the address bus width of the fpga_0_SRAM_A_pin vector to
be 32 bits the project will complete without errors.  However, I then
have to specify IO definitions for address lines 17-31 in the UCF
file.

Is there some setting I can use in the MHS to get the Xilinx EDK to
accept that my address bus to the SRAM is 17 bits rather than 31
bits?  I can't seem to find a parameter for the xps_mch_emc block that
lets me specify the width of the external address bus.

The relevant portions of the MHS file are show below.

Thanks!

Mike Thompson


-----------------------------------------------------------
...

 PORT fpga_0_SRAM_DQ_pin = fpga_0_SRAM_DQ, DIR = IO, VEC = [7:0]
 PORT fpga_0_SRAM_A_pin = fpga_0_SRAM_A, DIR = O, VEC = [16:0]
 PORT fpga_0_SRAM_WEN_pin = fpga_0_SRAM_WEN, DIR = O
 PORT fpga_0_SRAM_OEN_pin = fpga_0_SRAM_OEN, DIR = O, VEC = [0:0]
...

BEGIN xps_mch_emc
 PARAMETER INSTANCE = SRAM
 PARAMETER HW_VER = 2.00.a
 PARAMETER C_MAX_MEM_WIDTH = 8
 PARAMETER C_MEM0_WIDTH = 8
 PARAMETER C_SYNCH_MEM_0 = 0
 PARAMETER C_MCH_PLB_CLK_PERIOD_PS = 20000
 PARAMETER C_NUM_BANKS_MEM = 1
 PARAMETER C_INCLUDE_DATAWIDTH_MATCHING_0 = 1
 PARAMETER C_TCEDV_PS_MEM_0 = 70000
 PARAMETER C_TWC_PS_MEM_0 = 50000
 PARAMETER C_TAVDV_PS_MEM_0 = 70000
 PARAMETER C_TWP_PS_MEM_0 = 50000
 PARAMETER C_THZCE_PS_MEM_0 = 25000
 PARAMETER C_TLZWE_PS_MEM_0 = 0
 PARAMETER C_THZOE_PS_MEM_0 = 35000
 PARAMETER C_XCL0_WRITEXFER = 0
 PARAMETER C_MCH1_ACCESSBUF_DEPTH = 8
 PARAMETER C_MEM0_BASEADDR = 0x81420000
 PARAMETER C_MEM0_HIGHADDR = 0x8143ffff
 BUS_INTERFACE SPLB = mb_plb
 BUS_INTERFACE MCH0 = ixcl
 BUS_INTERFACE MCH1 = dxcl
 PORT Mem_A = fpga_0_SRAM_A
 PORT Mem_DQ = fpga_0_SRAM_DQ
 PORT Mem_WEN = fpga_0_SRAM_WEN
 PORT Mem_OEN = fpga_0_SRAM_OEN
 PORT RdClk = sys_clk_s
END
-----------------------------------------------------------


Article: 136886
Subject: Re: Sampling a clock
From: Rob <buzoff@leavemealone.com>
Date: Wed, 10 Dec 2008 21:55:33 -0500
Links: << >>  << T >>  << A >>
doug wrote:
> 
> 
> Rob wrote:
>> On Dec 10, 2:13 pm, doug <x...@xx.com> wrote:
>>
>>> Rob wrote:
>>>
>>>> On Dec 10, 12:14 pm, KJ <kkjenni...@sbcglobal.net> wrote:
>>>
>>>>> On Dec 10, 11:43 am, Rob <robns...@frontiernet.net> wrote:
>>>
>>>>>> There are no asynchronous inputs.  All the inputs are sync'd to the
>>>>>> incoming slow 6kHz clock.  The other fast internal FPGA MHz clock is
>>>>>> for something completely unrelated and has nothing to do with the SM.
>>>
>>>>>> Rob- Hide quoted text -
>>>
>>>>> Maybe add a free running counter that is clocked by the 6kHz clock
>>>>> that counts from 0 to 24 and then goes back to 0 resetting it only
>>>>> during powerup.  Bring the counter out to debug pins.  If your
>>>>> original hypothesis is correct that "...there is a spurious edge which
>>>>> my SM reacts to, thus causing erroneous data to be latched." then this
>>>>> counter would at some point end up at a non-zero count between
>>>>> transmissions (I'm assuming here that the transmissions are not
>>>>> continuous and there are identifiable gaps in time during which the
>>>>> state machine is waiting for the next 25 clock transmission to
>>>>> occur).  With that setup you can also look for times when the counter
>>>>> changes states quicker than the expected 6 kHz rate.  It can be a tad
>>>>> difficult depending on what equipment you can bring to bear and how
>>>>> many debug pins you have in your FPGA, but at least it gives you a
>>>>> direct view of flops inside the device that are being clocked and that
>>>>> will change state with every clock.
>>>
>>>> I already have a counter (that counts from 0 to 24) tied to the
>>>> incoming 6kHz clock. It is this counter that determines where I am in
>>>> the serial stream; and thus determines which flop within my data
>>>> register gets clocked with the incoming data.  But yes, I have already
>>>> thought about doing this.  But I don't need to--read below.
>>>
>>>>> Building somewhat further on that approach, if the state machine
>>>>> already has a signal that identifies the 'waiting for a new
>>>>> transmission to occur' time, then you could gate that signal with the
>>>>> counter being 0 and simply output a '1' when the protocol has been
>>>>> broken.  That gives you one specific signal to monitor to trigger the
>>>>> scope.
>>>
>>>>> Either of those approaches though is only meant to give you a known
>>>>> reliable trigger mechanism for a scope or logic analyzer so you can
>>>>> investigate further (if it triggers) or reject your hypothesis (if it
>>>>> does not).
>>>
>>>>> It's also not really clear whether you have such a trigger condition
>>>>> or if you're relying on perhaps some higher level system observation
>>>>> instead.  Your original thought to build a pulse monitor was somewhat
>>>>> along these lines, the problem with that approach though is that
>>>>> you're jumping to a solution that has holes to it.  Even if your
>>>>> hypothesis is correct you haven't actually verified the root cause
>>>>> problem.
>>>
>>>> I did build the pulse monitor and the problem got worse.  This of
>>>> course told me that I must be fighting a timing that is on the hairy
>>>> edge, as there is a slight delay through my "filter".  So I started
>>>> looking at the path in much more scrutiny and found a section of the
>>>> placement that didn't have a lot of margin.  I tightened this up and
>>>> the problems have disappeared.  This obviously makes more sense since
>>>> I never saw any glitches/runts on the scope.  And it also explains why
>>>> some boards worked and some didn't.
>>>
>>>> Again, I appreciate the dialogue....
>>>
>>> If this is an issue of the relative timing of the clock and data
>>> as you note above, why not just take the data on the other edge
>>> of the clock where it is stable and there are no timing issues
>>> at all?
>>
>>
>> The master sends out the data on the falling edge so one would think
>> that since I'm using the rising edge of the clock that there would be
>> plenty of tsu time.
> 
> Are you feeding the clock signal into the fpga on a clock pin or
> a data pin?  Any signals that go around on nonclock nets and
> get used for clocks at some point are going to be trouble because
> the skew will make shift registers very unpredictable.  What you
> are describing sounds like that since you are taking the data
> on the "good" side of the clock.  You could also use your internal
> clock to make a latch and filter on the clock line and the rising edge
> detection after the filter could enable a shift.

The clock is on a clock pin and feeds the global clock network.

Article: 136887
Subject: mapping to custom architecture
From: Ben D <bsdevlin@gmail.com>
Date: Wed, 10 Dec 2008 21:32:04 -0800 (PST)
Links: << >>  << T >>  << A >>
Hi everyone,

I am a masters student at, studying a pipelined FPGA model. What I
want to do is convert a Verilog HDL file to a custom FPGA architecture
eg, to a FPGA with 3 input LUTS and no carry support etc, a very basic
architecture.

Is there any way to specify my own part, so that a mapper will map to
a 3-lut instead? (i was using quatrus_map, but I can't get it to map
to a custom architecture)

I also tried using VPR/ODIN, but had some problems. Also I feel maybes
its overkill? Basically I just want to use a verilog hdl mapper but I
want to change the architecture its mapping to. Is there any kind of
open standard I can use to specify my FPGA architecture? (ie the lut
suze, flip flops, fanout, fpga size, etc)

Any help pointing me in the right direction would be a great help, Im
a little bit confused at where to start.

Thanks

Article: 136888
Subject: Re: Xilinx ISE 10.1 SP3 MPMC NPI VHDL simple sample needed
From: Matthias Alles <REMOVEallesCAPITALS@NOeit.SPAMuni-kl.de>
Date: Thu, 11 Dec 2008 09:43:25 +0100
Links: << >>  << T >>  << A >>
Hi!

I think that the MPMC documentation is a good starting point here (part
of the EDK). All the signals of the NPI interface are explained here.
Furthermore, timing diagrams show how using it should look like.
I was able to use the interface with this documentation. In Genode we
use the NPI interface to read pixel data from the memory or to clear a
memory region by bursts rather than by software. The code there is not
so easy to understand though, since there is quite a lot of overhead for
the framebuffer controlling (fpga-graphics.org). Another VGA controller
using the NPI is available on opencores.org.

Matthias



google@schwarzers.de schrieb:
> Hello all,
> 
> as a newbe with FPGAs I have no clue how to use the NPI interface of
> the MPMC from Xilinx.
> I haven't found a really good example.
> What I need is a simple module in VHDL which reads and writes the
> memory (maybe a simple memory test).
> 
> Is there something available ??? Can someone help me out ?
> 
> Thanks a lot!
> 
> /HB

Article: 136889
Subject: Re: mapping to custom architecture
From: Andreas Ehliar <ehliar-nospam@isy.liu.se>
Date: Thu, 11 Dec 2008 11:26:39 +0000 (UTC)
Links: << >>  << T >>  << A >>
On 2008-12-11, Brian Drummond <brian_drummond@btconnect.com> wrote:
> One option would be to translate a post-synthesis netlist (e.g. from
> Quartus or Xilinx Webpack) which has already been translated into a
> finite set of primitives; 4-LUTs, carry structures and the like.

You should probably read the EULA thoroughly before doing this though.
I believe that all major FPGA vendors have some language in the EULA
which tries to prohibit you from doing this.

Perhaps you could download the source code to Icarus and see how hard
it would be to add synthesis support for your FPGA architecture
instead?

/Andreas

Article: 136890
Subject: Re: Adding 128Kx8 SRAM to Spartan 3E FPGA
From: ales.gorkic@gmail.com
Date: Thu, 11 Dec 2008 03:35:33 -0800 (PST)
Links: << >>  << T >>  << A >>
On Dec 11, 3:26 am, mpthompson <mpthomp...@gmail.com> wrote:
> On a Xilinx Spartan 3e FPGA, I'm attempting to use the XPS MCH EMC
> memory controller to connect with an 128Kx8 SRAM chip (CY62128DV30LL)
> using Xilinx 10.1 EDK.  If I attempt to specify the address bus as 17
> bits in the MHS file I'll get the following error when generating the
> bitstream:
>
> -----------------------------------------------------------
> ERROR:MDT - GLOBAL PORT:fpga_0_SRAM_A_pin CONNECTOR:fpga_0_SRAM_A -
>    C:\Xilinx\Projects\dlp-fpga_project_5\system.mhs line 21 - 32 bit-
> width
>    connector assigned to 17 bit-width port
> Completion time: 0.00 seconds
> ERROR:MDT - platgen failed with errors!
> -----------------------------------------------------------
>
> If I specify the address bus width of the fpga_0_SRAM_A_pin vector to
> be 32 bits the project will complete without errors.  However, I then
> have to specify IO definitions for address lines 17-31 in the UCF
> file.
>
> Is there some setting I can use in the MHS to get the Xilinx EDK to
> accept that my address bus to the SRAM is 17 bits rather than 31
> bits?  I can't seem to find a parameter for the xps_mch_emc block that
> lets me specify the width of the external address bus.
>
> The relevant portions of the MHS file are show below.
>
> Thanks!
>
> Mike Thompson
>
> -----------------------------------------------------------
> ...
>
>  PORT fpga_0_SRAM_DQ_pin = fpga_0_SRAM_DQ, DIR = IO, VEC = [7:0]
>  PORT fpga_0_SRAM_A_pin = fpga_0_SRAM_A, DIR = O, VEC = [16:0]
>  PORT fpga_0_SRAM_WEN_pin = fpga_0_SRAM_WEN, DIR = O
>  PORT fpga_0_SRAM_OEN_pin = fpga_0_SRAM_OEN, DIR = O, VEC = [0:0]
> ...
>
> BEGIN xps_mch_emc
>  PARAMETER INSTANCE = SRAM
>  PARAMETER HW_VER = 2.00.a
>  PARAMETER C_MAX_MEM_WIDTH = 8
>  PARAMETER C_MEM0_WIDTH = 8
>  PARAMETER C_SYNCH_MEM_0 = 0
>  PARAMETER C_MCH_PLB_CLK_PERIOD_PS = 20000
>  PARAMETER C_NUM_BANKS_MEM = 1
>  PARAMETER C_INCLUDE_DATAWIDTH_MATCHING_0 = 1
>  PARAMETER C_TCEDV_PS_MEM_0 = 70000
>  PARAMETER C_TWC_PS_MEM_0 = 50000
>  PARAMETER C_TAVDV_PS_MEM_0 = 70000
>  PARAMETER C_TWP_PS_MEM_0 = 50000
>  PARAMETER C_THZCE_PS_MEM_0 = 25000
>  PARAMETER C_TLZWE_PS_MEM_0 = 0
>  PARAMETER C_THZOE_PS_MEM_0 = 35000
>  PARAMETER C_XCL0_WRITEXFER = 0
>  PARAMETER C_MCH1_ACCESSBUF_DEPTH = 8
>  PARAMETER C_MEM0_BASEADDR = 0x81420000
>  PARAMETER C_MEM0_HIGHADDR = 0x8143ffff
>  BUS_INTERFACE SPLB = mb_plb
>  BUS_INTERFACE MCH0 = ixcl
>  BUS_INTERFACE MCH1 = dxcl
>  PORT Mem_A = fpga_0_SRAM_A
>  PORT Mem_DQ = fpga_0_SRAM_DQ
>  PORT Mem_WEN = fpga_0_SRAM_WEN
>  PORT Mem_OEN = fpga_0_SRAM_OEN
>  PORT RdClk = sys_clk_s
> END
> -----------------------------------------------------------

You are obviously trying to connect 17bit Address pins to 32bit port
defined in your xps_mch_emc. You shold properly adjust Address (A) bus
width in your peripheral. Take a look at S3E Starter Kit reference
design or build one with a BSB.

Cheers,

Ales

Article: 136891
Subject: Re: Adding 128Kx8 SRAM to Spartan 3E FPGA
From: ales.gorkic@gmail.com
Date: Thu, 11 Dec 2008 03:47:38 -0800 (PST)
Links: << >>  << T >>  << A >>
On Dec 11, 3:26 am, mpthompson <mpthomp...@gmail.com> wrote:
> On a Xilinx Spartan 3e FPGA, I'm attempting to use the XPS MCH EMC
> memory controller to connect with an 128Kx8 SRAM chip (CY62128DV30LL)
> using Xilinx 10.1 EDK.  If I attempt to specify the address bus as 17
> bits in the MHS file I'll get the following error when generating the
> bitstream:
>
> -----------------------------------------------------------
> ERROR:MDT - GLOBAL PORT:fpga_0_SRAM_A_pin CONNECTOR:fpga_0_SRAM_A -
>    C:\Xilinx\Projects\dlp-fpga_project_5\system.mhs line 21 - 32 bit-
> width
>    connector assigned to 17 bit-width port
> Completion time: 0.00 seconds
> ERROR:MDT - platgen failed with errors!
> -----------------------------------------------------------
>
> If I specify the address bus width of the fpga_0_SRAM_A_pin vector to
> be 32 bits the project will complete without errors.  However, I then
> have to specify IO definitions for address lines 17-31 in the UCF
> file.
>
> Is there some setting I can use in the MHS to get the Xilinx EDK to
> accept that my address bus to the SRAM is 17 bits rather than 31
> bits?  I can't seem to find a parameter for the xps_mch_emc block that
> lets me specify the width of the external address bus.
>
> The relevant portions of the MHS file are show below.
>
> Thanks!
>
> Mike Thompson
>
> -----------------------------------------------------------
> ...
>
>  PORT fpga_0_SRAM_DQ_pin = fpga_0_SRAM_DQ, DIR = IO, VEC = [7:0]
>  PORT fpga_0_SRAM_A_pin = fpga_0_SRAM_A, DIR = O, VEC = [16:0]
>  PORT fpga_0_SRAM_WEN_pin = fpga_0_SRAM_WEN, DIR = O
>  PORT fpga_0_SRAM_OEN_pin = fpga_0_SRAM_OEN, DIR = O, VEC = [0:0]
> ...
>
> BEGIN xps_mch_emc
>  PARAMETER INSTANCE = SRAM
>  PARAMETER HW_VER = 2.00.a
>  PARAMETER C_MAX_MEM_WIDTH = 8
>  PARAMETER C_MEM0_WIDTH = 8
>  PARAMETER C_SYNCH_MEM_0 = 0
>  PARAMETER C_MCH_PLB_CLK_PERIOD_PS = 20000
>  PARAMETER C_NUM_BANKS_MEM = 1
>  PARAMETER C_INCLUDE_DATAWIDTH_MATCHING_0 = 1
>  PARAMETER C_TCEDV_PS_MEM_0 = 70000
>  PARAMETER C_TWC_PS_MEM_0 = 50000
>  PARAMETER C_TAVDV_PS_MEM_0 = 70000
>  PARAMETER C_TWP_PS_MEM_0 = 50000
>  PARAMETER C_THZCE_PS_MEM_0 = 25000
>  PARAMETER C_TLZWE_PS_MEM_0 = 0
>  PARAMETER C_THZOE_PS_MEM_0 = 35000
>  PARAMETER C_XCL0_WRITEXFER = 0
>  PARAMETER C_MCH1_ACCESSBUF_DEPTH = 8
>  PARAMETER C_MEM0_BASEADDR = 0x81420000
>  PARAMETER C_MEM0_HIGHADDR = 0x8143ffff
>  BUS_INTERFACE SPLB = mb_plb
>  BUS_INTERFACE MCH0 = ixcl
>  BUS_INTERFACE MCH1 = dxcl
>  PORT Mem_A = fpga_0_SRAM_A
>  PORT Mem_DQ = fpga_0_SRAM_DQ
>  PORT Mem_WEN = fpga_0_SRAM_WEN
>  PORT Mem_OEN = fpga_0_SRAM_OEN
>  PORT RdClk = sys_clk_s
> END
> -----------------------------------------------------------

One more thing. Usually the bus is splitted with "util_bus_split" core.

Article: 136892
Subject: Doubt about the maximum speed of FPGA clock nets
From: Andreas Ehliar <ehliar-nospam@isy.liu.se>
Date: Thu, 11 Dec 2008 12:08:37 +0000 (UTC)
Links: << >>  << T >>  << A >>

When reading for example the Virtex 4 datasheet under
switching characteristics. More specifically the section
named "Clock Buffers and Networks", there is a value
F_MAX which is specified as the maximum frequency for
a global clock tree. This value is 500 MHz in a Virtex-4
speedgrade 12.

However, when synthesizing simple designs which are heavily
pipelined it is easy to get a design which the static timing
analysis tool reports as having a maximum frequency of
significantly higher than 500 MHz in a speedgrade 12 device.

There is no warning in the trce output about exceeding F_MAX.

Since I have bitten in the past by the static timing analyser [1]
I thought it best to ask here whether trce is right in ignoring
F_MAX or not.

(I tried to ask this on the message board on Xilinx' website but
never got a satisfactory answer.)

/Andreas

[1] http://www.google.com/url?q=http://groups.google.com/g/3f77ff01/t/b9de1a095ac08f5a/d/54a6b4955bca044d%3Fie%3Dutf-8%26oe%3Dutf-8%26q%3Dcontradicting%2Bmessages%2Behliar%2354a6b4955bca044d&usg=AFQjCNFW8HKRjzEDkVdYxGbCJQgKIN5MoQ

Article: 136893
Subject: Re: Adding 128Kx8 SRAM to Spartan 3E FPGA
From: Brian Drummond <brian_drummond@btconnect.com>
Date: Thu, 11 Dec 2008 13:12:57 +0000
Links: << >>  << T >>  << A >>
On Wed, 10 Dec 2008 18:26:37 -0800 (PST), mpthompson
<mpthompson@gmail.com> wrote:

>On a Xilinx Spartan 3e FPGA, I'm attempting to use the XPS MCH EMC
>memory controller to connect with an 128Kx8 SRAM chip (CY62128DV30LL)
>using Xilinx 10.1 EDK.  
>
>If I specify the address bus width of the fpga_0_SRAM_A_pin vector to
>be 32 bits the project will complete without errors.  However, I then
>have to specify IO definitions for address lines 17-31 in the UCF
>file.

In EDK 7.1 there used to be an IP core you could instantiate, simply to
extract a slice out of a longer word. Maybe it's still there? (Sorry, I
can't remember its name but it should be easy to find)

It seemed like a sledgehammer to crack a nut, but it kept the design
within the EDK [paradigm|straitjacket], and I think it will do what you
want.

Instead I just used my EDK project as a component within an ISE project,
so I was free to do anything I wanted outside it.

- Brian


Article: 136894
Subject: Re: mapping to custom architecture
From: Brian Drummond <brian_drummond@btconnect.com>
Date: Thu, 11 Dec 2008 13:40:47 +0000
Links: << >>  << T >>  << A >>
On Wed, 10 Dec 2008 21:32:04 -0800 (PST), Ben D <bsdevlin@gmail.com>
wrote:

>Hi everyone,
>
>I am a masters student at, studying a pipelined FPGA model. What I
>want to do is convert a Verilog HDL file to a custom FPGA architecture
>eg, to a FPGA with 3 input LUTS and no carry support etc, a very basic
>architecture.
>
>Is there any way to specify my own part, so that a mapper will map to
>a 3-lut instead? (i was using quatrus_map, but I can't get it to map
>to a custom architecture)

If you can't find a general solution...

One option would be to translate a post-synthesis netlist (e.g. from
Quartus or Xilinx Webpack) which has already been translated into a
finite set of primitives; 4-LUTs, carry structures and the like.

You can reduce the set of primitives somewhat, either by targeting
older, simpler FPGAs or by setting synthesis options to avoid special
features (MUXF5,6 and MULT18).

Then you only have to transform each of those primitives into your
target technology (LUT being trivial when 3 or fewer inputs used!)
and you have a solution of sorts ... locally sub-optimal (e.g. where you
translated carry chain to LUTs) but easy to get correct. Local
optimisations may be possible as a separate step.

Extract a list of primitives from an example netlist to gauge the size
of the problem. 

Scanning one such (Xilinx) netlist shows two "CY" primitives
(MUXCY,XORCY), many LUT2 and INV and FD components (and a MULT18, ahem!)
forming the vast majority of them.

- Brian

Article: 136895
Subject: Re: Xilinx ISE 10.1 SP3 MPMC NPI VHDL simple sample needed
From: hardbreaker <google@schwarzers.de>
Date: Thu, 11 Dec 2008 06:12:45 -0800 (PST)
Links: << >>  << T >>  << A >>
Does someone has a mini EDK project with sources for me ?
I would really appreciate it ... :-)

Article: 136896
Subject: Re: Sampling a clock
From: colin <colin_toogood@yahoo.com>
Date: Thu, 11 Dec 2008 06:42:05 -0800 (PST)
Links: << >>  << T >>  << A >>
The pulse will be twice or half as long as normal depending on whether
you get an extra trigger on the rising or falling edge. You can just
trigger on the rising edge and look at the output a couple of clocks
later. It should be a clock, but if you get an eye diagram then you
got an extra clock on the the clock and if your clock shifts by 90
degrees then you got a rising edge during the falling edge.


Colin


Article: 136897
Subject: Re: Sampling a clock
From: KJ <kkjennings@sbcglobal.net>
Date: Thu, 11 Dec 2008 08:19:15 -0800 (PST)
Links: << >>  << T >>  << A >>
On Dec 10, 1:05=A0pm, Rob <robns...@frontiernet.net> wrote:

>
> I did build the pulse monitor and the problem got worse. =A0This of
> course told me that I must be fighting a timing that is on the hairy
> edge, as there is a slight delay through my "filter". =A0So I started
> looking at the path in much more scrutiny and found a section of the
> placement that didn't have a lot of margin. =A0I tightened this up and
> the problems have disappeared. =A0This obviously makes more sense since
> I never saw any glitches/runts on the scope. =A0And it also explains why
> some boards worked and some didn't.
>

A "path that didn't have a lot of margin" where you "tightened this up
and the problems have disappeared" on a design that that is running at
6 kHz in an FPGA where the 6 kHz clock is coming in on a clock pin and
the inputs change on the opposite edge of the receiving clock is
somewhat nonsensical.

Presumably the path you've run across is in fact a clock domain
transfer between the 6 kHz and the FPGA's main clock.  Assuming that,
if you insist on using the 6 kHz input as a clock input to a register
then the only way to correct the design 100% is
- Proper handshaking across the interface
- A dual clock fifo would (but this would likely be overkill here)

If your fix did not change the source code logic description to
implement one of the above two methods, but instead only involved
adding or manipulating fitter timing/placement/whatever constraints
then you haven't really fixed the problem, it will come back to bite
you with near 100% certainty.

Based on your description, it appears the FPGA implements a SPI slave
external interface that is controlled by some external processor.
Presumably the processor needs to setup control registers and read
back status from the FPGA for the system to work.  At some point in
such a system there will have to be a clock domain crossing.

Since there is probably a large difference between the main FPGA clock
frequency and the SPI clock frequency of 6 kHz, a much more robust and
simpler approach then the two listed above would have been to simply
synchronize the SPI bus inputs (including clock) to the FPGA clock as
one would do with any other asynchronous input.  Then look for the SPI
clock transitions within the FPGA clock domain, the SPI clock input
signal would not be used as a clock input to any registers.  That way
there is only one clock domain, not two so there is no clock domain
crossing issue.

Whenever you have a large frequency difference between two 'clocks'
and the setup/hold times are rather relaxed this approach should
always be the first solution to persue.

Kevin Jennings

Article: 136898
Subject: How to insert ChipScope
From: Marlboro <ccon67@netscape.net>
Date: Thu, 11 Dec 2008 09:37:46 -0800 (PST)
Links: << >>  << T >>  << A >>
Just a polling question, which way people use the most to insert the
Chipscope into the design?

For my own, if using the Inserter to add Chipscope to the ngc netlist,
then there're chances the Tranlate step has changed your net names
around make it difficult to see and attach what you have built and
want to attach to the scope

Thnks





Article: 136899
Subject: Re: Adding 128Kx8 SRAM to Spartan 3E FPGA
From: Bryan <bryan.fletcher@avnet.com>
Date: Thu, 11 Dec 2008 09:46:34 -0800 (PST)
Links: << >>  << T >>  << A >>
Avnet has an example using a 1Mx8 Cypress MicroPower SRAM with
Spartan-3A MicroBlaze (EDK 10.1.3).  You can find it at www.em.avnet.com/mx=
p-sram
--> Support Files & Downloads.  The example was generated using BSB,
which automatically instantiates IP UTIL_BUS_SPLIT to align the
busses.

Bryan

 PORT fpga_0_SRAM_1Mx8_Mem_A_pin =3D fpga_0_SRAM_1Mx8_Mem_A, DIR =3D O,
VEC =3D [12:31]
 PORT fpga_0_SRAM_1Mx8_Mem_DQ_pin =3D fpga_0_SRAM_1Mx8_Mem_DQ, DIR =3D IO,
VEC =3D [0:7]
 PORT fpga_0_SRAM_1Mx8_Mem_OEN_pin =3D fpga_0_SRAM_1Mx8_Mem_OEN, DIR =3D
O, VEC =3D [0:0]
 PORT fpga_0_SRAM_1Mx8_Mem_CEN_pin =3D fpga_0_SRAM_1Mx8_Mem_CEN, DIR =3D
O, VEC =3D [0:0]
 PORT fpga_0_SRAM_1Mx8_Mem_WEN_pin =3D fpga_0_SRAM_1Mx8_Mem_WEN, DIR =3D O
 PORT fpga_0_SRAM_1Mx8_Mem_CE_pin =3D fpga_0_SRAM_1Mx8_Mem_CE, DIR =3D O,
VEC =3D [0:0]

BEGIN xps_mch_emc
 PARAMETER INSTANCE =3D SRAM_1Mx8
 PARAMETER HW_VER =3D 2.00.a
 PARAMETER C_MCH_PLB_CLK_PERIOD_PS =3D 20833
 PARAMETER C_NUM_BANKS_MEM =3D 1
 PARAMETER C_INCLUDE_DATAWIDTH_MATCHING_0 =3D 1
 PARAMETER C_SYNCH_MEM_0 =3D 0
 PARAMETER C_MEM0_WIDTH =3D 8
 PARAMETER C_MAX_MEM_WIDTH =3D 8
 PARAMETER C_TCEDV_PS_MEM_0 =3D 45000
 PARAMETER C_TWC_PS_MEM_0 =3D 35000
 PARAMETER C_TAVDV_PS_MEM_0 =3D 45000
 PARAMETER C_TWP_PS_MEM_0 =3D 35000
 PARAMETER C_THZCE_PS_MEM_0 =3D 0
 PARAMETER C_TLZWE_PS_MEM_0 =3D 0
 PARAMETER C_MCH0_ACCESSBUF_DEPTH =3D 4
 PARAMETER C_XCL0_WRITEXFER =3D 0
 PARAMETER C_MCH1_ACCESSBUF_DEPTH =3D 8
 PARAMETER C_MEM0_BASEADDR =3D 0x84900000
 PARAMETER C_MEM0_HIGHADDR =3D 0x849fffff
 BUS_INTERFACE SPLB =3D mb_plb
 BUS_INTERFACE MCH0 =3D ixcl
 BUS_INTERFACE MCH1 =3D dxcl
 PORT Mem_A =3D fpga_0_SRAM_1Mx8_Mem_A_split
 PORT Mem_DQ =3D fpga_0_SRAM_1Mx8_Mem_DQ
 PORT Mem_OEN =3D fpga_0_SRAM_1Mx8_Mem_OEN
 PORT Mem_CEN =3D fpga_0_SRAM_1Mx8_Mem_CEN
 PORT Mem_WEN =3D fpga_0_SRAM_1Mx8_Mem_WEN
 PORT Mem_CE =3D fpga_0_SRAM_1Mx8_Mem_CE
 PORT RdClk =3D sys_clk_s
END

BEGIN util_bus_split
 PARAMETER INSTANCE =3D SRAM_1Mx8_util_bus_split_1
 PARAMETER HW_VER =3D 1.00.a
 PARAMETER C_SIZE_IN =3D 32
 PARAMETER C_LEFT_POS =3D 0
 PARAMETER C_SPLIT =3D 12
 PORT Sig =3D fpga_0_SRAM_1Mx8_Mem_A_split
 PORT Out2 =3D fpga_0_SRAM_1Mx8_Mem_A
END


On Dec 11, 6:12=A0am, Brian Drummond <brian_drumm...@btconnect.com>
wrote:
> On Wed, 10 Dec 2008 18:26:37 -0800 (PST), mpthompson
>
> <mpthomp...@gmail.com> wrote:
> >On a Xilinx Spartan 3e FPGA, I'm attempting to use the XPS MCH EMC
> >memory controller to connect with an 128Kx8 SRAM chip (CY62128DV30LL)
> >using Xilinx 10.1 EDK. =A0
>
> >If I specify the address bus width of the fpga_0_SRAM_A_pin vector to
> >be 32 bits the project will complete without errors. =A0However, I then
> >have to specify IO definitions for address lines 17-31 in the UCF
> >file.
>
> In EDK 7.1 there used to be an IP core you could instantiate, simply to
> extract a slice out of a longer word. Maybe it's still there? (Sorry, I
> can't remember its name but it should be easy to find)
>
> It seemed like a sledgehammer to crack a nut, but it kept the design
> within the EDK [paradigm|straitjacket], and I think it will do what you
> want.
>
> Instead I just used my EDK project as a component within an ISE project,
> so I was free to do anything I wanted outside it.
>
> - Brian




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